| 00:00.15 | *** join/#storm wallflower (n=wallflow@ip-205-246-113-216.pool.grokthis.net) |
| 00:12.55 | *** join/#storm aklaver (n=aklaver@c-67-160-97-72.hsd1.wa.comcast.net) |
| 00:55.43 | *** join/#storm jukart (n=jukart@85-124-221-45.static.xdsl-line.inode.at) |
| 02:51.36 | *** join/#storm bigdog (n=scmikes@8.8.197.72) |
| 05:53.19 | *** join/#storm dobee (n=dobeee@194.183.146.186) |
| 06:08.57 | *** join/#storm jukart (n=jukart@85-124-221-45.static.xdsl-line.inode.at) |
| 06:40.51 | *** join/#storm jukart (n=jukart@194.183.146.181) |
| 06:53.52 | *** join/#storm dobee (n=dobeee@194.183.146.186) |
| 07:29.58 | *** join/#storm bozzo (n=bozzo@85.10.14.223) |
| 11:15.15 | *** join/#storm niemeyer (n=niemeyer@200-138-134-89.ctame705.dsl.brasiltelecom.net.br) |
| 11:22.07 | *** join/#storm Key_Gena (i=lok@gateway/tor/x-beb5aeaa9431be06) |
| 11:35.11 | *** join/#storm bozzo_ (n=bozzo@85.10.14.223) |
| 12:40.36 | *** join/#storm Key_Gena (i=lok@gateway/tor/x-7341e09a27e69c0d) |
| 14:40.54 | radix | pyCube: :-) |
| 14:41.20 | pyCube | hi |
| 15:38.04 | *** join/#storm bigdo1 (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
| 15:39.12 | *** join/#storm michelp (n=michelp@69-30-72-119.dq1sf.easystreet.com) |
| 16:06.45 | *** join/#storm mcella (n=michele@ip-171-181.sn3.eutelia.it) |
| 17:09.01 | *** join/#storm Zenom (n=Zenom@unaffiliated/aj1973) |
| 17:09.05 | Zenom | anyone here? |
| 17:09.34 | niemeyer | Zenom: We are |
| 17:09.47 | niemeyer | Zenom: But in a meeting, so slightly delayed |
| 17:09.51 | Zenom | i am curious how to implement a connection pooling type mechanism |
| 17:10.03 | Zenom | or best practice for integrating storm into something like cherrypy |
| 17:10.57 | Zenom | i put a message on the mailing list like a week ago and no responses there either |
| 17:10.59 | gpolo | what is the problem to use it in cherrypy ? |
| 17:11.11 | Zenom | im trying to figure out how to |
| 17:11.18 | Zenom | ie., 1 connection per thread, |
| 17:11.29 | Zenom | if so how do I monitor said connection, and re-connect if it fails etc |
| 17:12.20 | gpolo | you would do this inside your storm code |
| 17:12.38 | *** join/#storm Key_Gena (i=lok@gateway/tor/x-40dc85127cce8a59) |
| 17:12.43 | Zenom | gpolo: any examples? thats what i am trying to figure out, ie., if there is some sort of connection pooling etc |
| 17:13.14 | gpolo | uhm, i don't have any examples with me |
| 17:13.39 | Zenom | hmm |
| 17:17.06 | Zenom | any direction? sites to look at? the docs for storm are pretty lacking |
| 17:17.30 | jkakar | Zenom: Are you using PostgreSQL? jamesh recently landed a disconnection branch that raises DisconnectionError when a connection is dropped. |
| 17:17.43 | jkakar | It's in trunk, not in a release yet. |
| 17:17.58 | Zenom | yes postgresql |
| 17:18.21 | Zenom | jkakar: i guess my problem is i am trying to figure out how to receive said exception and where/when to reconnect etc |
| 17:18.31 | Zenom | on a per thread basis |
| 17:18.37 | Zenom | or do I need to do it on a per request bassis |
| 17:19.04 | jkakar | Zenom: Right. The way it's been implemented in Storm is to make it the app's problem to determine what to do. The dropped connection is re-connected automatically, as I recall. |
| 17:20.03 | jkakar | Zenom: I guess you'd do it on a per-thread basis if you have one store/thread and then, ideally, replay the request. |
| 17:20.27 | Zenom | what are most people doing right now? |
| 17:20.32 | Zenom | i mean this has to have come up |
| 17:20.42 | jkakar | Yeah, I'm not sure what most people are doing. Probably nothing. |
| 17:27.43 | niemeyer | Zenom: I'll take care of your message shortly about this meeting |
| 17:27.55 | Zenom | niemeyer: ok |
| 17:27.56 | niemeyer | Zenom: I understand your question, and we have a pattern we use in zstorm for it |
| 17:54.32 | *** join/#storm jukart (n=jukart@85-124-221-45.static.xdsl-line.inode.at) |
| 17:59.07 | niemeyer | Zenom: Alright |
| 17:59.19 | niemeyer | Zenom: Meeting is over, I'll address your question now |
| 17:59.22 | Zenom | please help me use storm :) |
| 17:59.35 | Zenom | sqlalchemy and dejavu are way over the top |
| 18:00.08 | Zenom | being that there is no connection pooling mechanism like sqlalchemy with storm |
| 18:00.25 | Zenom | i need to know how to connect storm up per thread and monitor said connections so that if the connection dies the thread isn't useless |
| 18:02.00 | radix | Zenom: Basically, you want to make sure you have one Store object per thread |
| 18:02.22 | Zenom | radix: and what happens if that Store object dissapears, dies, blows up? |
| 18:02.39 | radix | Zenom: I assume you mean "what happens if the connection is lost"? |
| 18:02.45 | Zenom | exactly |
| 18:02.56 | niemeyer | Zenom: Right.. that's what I'm answering in the mail |
| 18:03.09 | Zenom | niemeyer: cool |
| 18:05.10 | Zenom | i mean maybe I am missing something |
| 18:05.18 | Zenom | are most people not using multi-threaded apps? |
| 18:05.25 | Zenom | or just like using mod_python ? |
| 18:05.33 | radix | we are using multi-threaded apps |
| 18:05.55 | radix | Zenom: Storm doesn't currently handle disconnects for you, but that functionality is in progress |
| 18:06.09 | radix | Zenom: we're using Storm in production systems even so |
| 18:06.43 | Zenom | yeah but for mission critical stuff like lets say billing |
| 18:06.50 | Zenom | if a thread doesn't have the connection |
| 18:07.07 | Zenom | it will just error out with out some sort of checking/re-connecting |
| 18:07.35 | radix | yeah, and that's why the reconnection feature is in progress :) |
| 18:08.03 | radix | but regardless, the way you should write your app is to have one Store per thread |
| 18:08.14 | radix | when the reconnection logic gets merged and release, it will transparently start working |
| 18:08.48 | Zenom | yeah i guess maybe I am just concerned the connection dissapears |
| 18:08.53 | Zenom | and our users don't have access |
| 18:09.31 | radix | certainly |
| 18:09.53 | radix | Zenom: when do you plan the app to go into production? |
| 18:11.09 | niemeyer | radix: The reconnect stuff is merged on trunk, actually |
| 18:11.10 | Zenom | within the next 1-2 weeks |
| 18:12.04 | Zenom | so in trunk it will auto-reconnect? |
| 18:12.10 | niemeyer | Zenom: It will |
| 18:12.30 | Zenom | so as long as I create 1 store per thread, then I should be golden? |
| 18:12.53 | niemeyer | radix: It's one of the things I've done with James during the sprint.. it had a review, I gave the second one and exchanged some ideas with James |
| 18:13.06 | niemeyer | Zenom: Pretty much |
| 18:13.09 | radix | cool |
| 18:13.14 | niemeyer | Zenom: You can actually have multiple stores per thread |
| 18:13.19 | Zenom | ok where do i find the svn co for trunk |
| 18:13.29 | niemeyer | Zenom: I've just answered your mail, which hopefully explains some of that |
| 18:13.38 | niemeyer | Zenom: bzr branch lp:storm |
| 18:13.40 | Zenom | ok cool let me check |
| 18:14.04 | Zenom | everyone is using a new rcs now lol |
| 18:14.10 | Zenom | svn, hg, git, bzr |
| 18:14.14 | Zenom | haha |
| 18:14.29 | gpolo | bzr is not so new |
| 18:15.08 | niemeyer | Zenom: I can't imagine myself using svn anymore :) |
| 18:15.21 | gpolo | i haven't used bzr myself |
| 18:15.26 | gpolo | still svn and git |
| 18:17.07 | niemeyer | I have a few projects under svn still, and everytime I use them I think "Man, I have to migrate that." |
| 18:29.08 | *** join/#storm jkakar (n=jkakar@dhcp802-1-85.dsl.ucc-net.ca) |
| 18:31.54 | Zenom | http://pastie.caboo.se/117426 |
| 18:32.00 | Zenom | i am thinking something like that *should* work |
| 18:32.07 | Zenom | for a store per thread |
| 18:33.01 | Zenom | macports has been so jacked since leopard |
| 18:35.27 | niemeyer | Zenom: Possibly |
| 18:35.56 | niemeyer | Zenom: It's limiting to a single store, though |
| 18:36.06 | niemeyer | Zenom: I'd also be inclined to s/db/store/ |
| 18:36.15 | niemeyer | Zenom: So that people know what they're dealing with |
| 18:36.22 | Zenom | yeah i am trying to understand/figure out how to do multiple stores per thread |
| 18:36.31 | niemeyer | Zenom: That's what zstorm would offer |
| 18:36.39 | Zenom | im still fairly knew to python only using for a month |
| 18:36.42 | niemeyer | Zenom: Or CPyStorm :) |
| 18:36.42 | Zenom | let me look at zstorm |
| 18:42.25 | niemeyer | Zenom: In that case I'd advise you to just go with the simplest for the moment |
| 18:42.43 | Zenom | hehe yeah our site gets high traffic thats why i am even worrying about it |
| 18:42.56 | Zenom | also for postgresql schemas do I just put that in the __table__ or whatever? |
| 18:43.22 | Zenom | and for existing tables do I need to define all their attributes? |
| 19:03.25 | *** join/#storm dobee (n=dobeee@81-223-53-162.dornbirn.xdsl-line.inode.at) |
| 19:03.52 | niemeyer | Zenom: You don't have to define all their attributes, as long as the database won't be mad about insert statements with these fields missing |
| 19:04.13 | Zenom | ok |
| 19:04.31 | niemeyer | Zenom: For postgresql schemas, there's a small inconvenience that we have to fix.. it's not a big deal, but the value you provide to __storm_table__ is currently escaped |
| 19:05.04 | niemeyer | Zenom: Escaping public.foo as "public.foo" makes PostgreSQL slightly upset :) |
| 19:05.40 | niemeyer | Zenom: I'll be happy to fix that if you get blocked on it |
| 19:05.50 | Zenom | i tried it manually and it worked |
| 19:05.53 | *** join/#storm EnTeQuAk (n=EnTeQuAk@dslb-088-074-058-134.pools.arcor-ip.net) |
| 19:06.06 | Zenom | i had __storm_table__ = "admin.sites" |
| 19:06.11 | Zenom | and it seemed to work it returned the site name |
| 19:10.07 | Zenom | niemeyer: do I need to worry about disconnecting from storm as well when the thread dies? or the application server quits? |
| 19:10.14 | Zenom | and if so is there a way to release the stores? |
| 19:11.10 | niemeyer | Zenom: Hmm.. you shouldn't need any special handling for that |
| 19:11.16 | Zenom | ok |
| 19:11.28 | niemeyer | Zenom: But maybe it depends on your application server, and on the way it's hooked in the transaction system |
| 19:11.48 | niemeyer | Zenom: E.g. you don't want a Store that won't be rolled back nor committed being held with a strong reference. |
| 19:12.06 | Zenom | i dont think i will have that, its simple queries, updates |
| 19:12.12 | Zenom | not something that is kept open perm |
| 19:12.13 | niemeyer | Zenom: Since the connection will stay alive, and thus create other complications in the database side such as idle transactions. |
| 19:17.40 | *** join/#storm bozzo (n=bozzo@89-212-214-93.dynamic.dsl.t-2.net) |
| 19:21.24 | Zenom | ok i got it all working now to figure out how to do the pooling hehe |
| 19:22.00 | Zenom | http://tools.cherrypy.org/wiki/Storm |
| 19:25.08 | Zenom | niemeyer: is there a repo for zstorm? |
| 19:25.21 | niemeyer | Zenom: It's in storm.zope |
| 19:25.38 | Zenom | https://code.launchpad.net/~jkakar/storm/storm-zope ? |
| 19:25.51 | *** join/#storm bozzo (n=bozzo@89-212-214-93.dynamic.dsl.t-2.net) |
| 19:26.21 | Zenom | oh i see physically the dir |
| 19:26.22 | Zenom | gotcha |
| 19:27.31 | Zenom | do you plan on making a generic pooling mechanism that is not zope specific? |
| 19:28.47 | niemeyer | Zenom: Looks pretty nice |
| 19:29.01 | niemeyer | Zenom: I guess you didn't really understand what I explained in the mail :) |
| 19:29.14 | Zenom | it wouldn't be the first time :) |
| 19:29.26 | niemeyer | Zenom: I could probably have made it more clear |
| 19:29.29 | niemeyer | Zenom: So.. |
| 19:29.46 | niemeyer | Zenom: The idea is that polling is not needed in this context |
| 19:30.23 | niemeyer | Zenom: If you have worker threads which stay alive to handle several connections, the store *already* has a connection |
| 19:30.25 | Zenom | as long as I have 1 connection per thread that reconnects you mean, correct? |
| 19:30.42 | niemeyer | Zenom: Nope.. it won't reconnect |
| 19:30.52 | niemeyer | Zenom: The Store holds a reference to the connection |
| 19:31.09 | niemeyer | You don't need polling because you're holding of the store |
| 19:31.13 | niemeyer | s/of// |
| 19:31.19 | niemeyer | jbot: You're brilliant |
| 19:31.29 | Zenom | heh |
| 19:31.38 | Zenom | so basically because each of my cp threads has the store |
| 19:31.45 | Zenom | i don't need pooling, because each thread has that reference |
| 19:31.51 | Zenom | and will auto-connect etc., as its needed |
| 19:32.00 | Zenom | or am i still off? |
| 19:32.16 | niemeyer | Zenom: Right, *if* the connection is dropped (e.g. database restarted), it will reconnect |
| 19:32.27 | Zenom | it being the Store? |
| 19:32.49 | niemeyer | Zenom: It being the Connection which the Store holds, but that's a detail :) |
| 19:33.02 | Zenom | i think maybe my problem is in my thinking, so am i right in saying that there is no real connection until a query is called? |
| 19:33.13 | niemeyer | Zenom: No |
| 19:33.16 | Zenom | or is Store actually still an active pipe to the db |
| 19:33.30 | niemeyer | Zenom: The Store holds a connection to the database, yes :-) |
| 19:33.33 | Zenom | ok |
| 19:33.40 | Zenom | sorry I come from PHP |
| 19:33.43 | Zenom | so things are a little diff lol |
| 19:34.11 | niemeyer | Zenom: No worries.. I'm glad you've seen the light |
| 19:34.24 | Zenom | oh i enjoy python |
| 19:34.27 | Zenom | don't plan on going back |
| 19:34.43 | Zenom | and I am a big fan of canonical in general (we might be using debian servers for all 30 of our servers soon) |
| 19:34.50 | Zenom | so i wanted to use storm if at all possible |
| 19:35.34 | Zenom | so in your experience is there EVER a time that a thread needs more than a single Store? |
| 19:36.11 | niemeyer | Zenom: Hmm.. you're a big fan of Canonical and might be using *Debian* servers? :-) |
| 19:36.20 | Zenom | sorry i mean ubuntu |
| 19:36.33 | niemeyer | Zenom: Hmm |
| 19:36.42 | Zenom | i just get say debian all the time not sure why lol |
| 19:36.50 | niemeyer | Zenom: It depends.. |
| 19:36.58 | niemeyer | Zenom: But I can make you answer that question :) |
| 19:37.11 | niemeyer | Zenom: Is there ever a time that you need two connections to the database in your thread? |
| 19:37.25 | Zenom | well connecting to two separate databases |
| 19:37.31 | niemeyer | Bingo :) |
| 19:37.49 | Zenom | so in that instance I guess I could just create a one-off store, correct? |
| 19:37.58 | niemeyer | Probably |
| 19:38.00 | Zenom | or if I wanted a read store and a write store |
| 19:38.07 | Zenom | i would just create 2 stores at thread startup |
| 19:38.11 | niemeyer | But something like ZStorm would be a big win |
| 19:38.27 | niemeyer | Zenom: Also, there's one important thing missing from your integration in CherryPy |
| 19:38.49 | Zenom | ? |
| 19:38.52 | niemeyer | Zenom: Usually that kind of application benefits a lot of you integrate commit/rollback at the request boundary |
| 19:38.59 | niemeyer | s/of/if/ |
| 19:39.32 | Zenom | niemeyer: like an auto-commit type thing? not sure i follow |
| 19:39.32 | niemeyer | Zenom: So if the request succeeds, you commit the store at the end of the request handling.. if it fails, you roll it back |
| 19:39.42 | Zenom | gotcha |
| 19:39.57 | Zenom | http://tools.cherrypy.org/wiki/Dejavu |
| 19:40.05 | Zenom | something like they have for dejavu i am assuming |
| 19:41.25 | niemeyer | Zenom: I don't get it to be honest.. |
| 19:41.55 | Zenom | what the dejavu entry? |
| 19:41.59 | niemeyer | Zenom: I don't know what they call "a sandbox", nor what flushing all of it means |
| 19:42.14 | Zenom | sandbox is dejavu's term of store |
| 19:42.15 | Zenom | or session |
| 19:42.22 | niemeyer | Zenom: Do you have any other example? |
| 19:42.24 | Zenom | dejavu is really confusing with its terms |
| 19:42.30 | niemeyer | Zenom: SQLObject, SQLAlchemy? |
| 19:42.39 | Zenom | no |
| 19:42.46 | Zenom | i know what you mean though |
| 19:43.00 | niemeyer | Zenom: I also find it weird that they're just "flushing" it, regardless of the result |
| 19:43.49 | Zenom | basically you are saying like have something in the request method that says |
| 19:43.55 | Zenom | if store.add(...): |
| 19:43.59 | Zenom | cherrypy.request.flush() |
| 19:44.16 | Zenom | or I should say cherrypy.thread_data.store.flush() |
| 19:49.13 | Zenom | actually that would be cherrypy.thread_data.store.commit() as flush is auto-magic isn't it? |
| 19:50.29 | niemeyer | Zenom: Right! |
| 19:51.09 | niemeyer | Zenom: So it basically commit()s if the request succeeded, and rollback()s if it was a failure (an exception raised, 404, etc) |
| 19:51.27 | niemeyer | Zenom: Of course, it depends a bit on how CherryPy itself works |
| 19:51.34 | Zenom | right |
| 19:52.01 | niemeyer | Zenom: Some CherryPy expert might easily tell you the expected way to handle commit/rollback |
| 19:52.21 | Zenom | yeah i am talking to fumanchu about it now who is the lead on cherrypy |
| 19:52.44 | niemeyer | Zenom: Cool! |
| 19:53.35 | Zenom | niemeyer: lol he dissagrees haha |
| 19:53.44 | niemeyer | Zenom: Disagrees with what? |
| 19:54.00 | Zenom | he thinks its bad practice to assume like request status means its good i guess |
| 19:54.21 | Zenom | that would, for example, roll back a hit counter on a 204 no content or a 304 not modified |
| 19:54.22 | niemeyer | Zenom: Well.. he's not disagreeing.. he's telling you the way you should do it :) |
| 19:54.53 | niemeyer | Zenom: The right way to do it is platform-dependent |
| 19:55.17 | niemeyer | Zenom: A 304 not modified won't raise an error in Zope, for instance.. |
| 19:55.30 | Zenom | gotcha |
| 19:55.43 | niemeyer | Zenom: The whole platform *expects* that unhandled exceptions will roll the transaction back |
| 19:56.19 | niemeyer | Zenom: Where the "transaction manager" is something Storm just hooks into, and waits for the specific signals to be emitted |
| 19:56.41 | niemeyer | Zenom: So if the guy that is the platform's maintainer says "don't do it", I wouldn't do it :) |
| 20:09.50 | *** join/#storm EnTeQuAk (n=EnTeQuAk@dslb-088-072-205-097.pools.arcor-ip.net) |
| 20:10.04 | Zenom | niemeyer: thanks for the help i think i am on my way now :) |
| 20:23.07 | *** join/#storm Key_Gena (i=lok@gateway/tor/x-fd227e5abd3d5775) |
| 20:34.37 | Zenom | niemeyer: i can lookup tuples but cannot add new ones, is this possibly the schema bug you mentioned about it escaping items? |
| 20:34.51 | Zenom | http://pastie.caboo.se/117504 |
| 20:42.19 | Zenom | definitely the schema bug |
| 20:42.23 | Zenom | in public schema it works |
| 21:41.52 | niemeyer | Zenom: Aha.. ok |
| 21:42.50 | Zenom | niemeyer: any way to get that resolved? |
| 21:43.31 | niemeyer | Zenom: Sure thing, hold o |
| 21:43.32 | niemeyer | n |
| 22:04.58 | *** join/#storm oubiwann (n=oubiwann@71-34-198-159.omah.qwest.net) |
| 22:24.55 | Zenom | is there an easier way to sort items that are References? for example I have a Site table that has multiple Subscriptions |
| 22:25.06 | Zenom | i want to sort the subscriptions by price |
| 22:25.18 | Zenom | so like site.subscriptions.price |
| 22:35.41 | niemeyer | Zenom: site.subscriptions.order_by(Subscription.price) |
| 22:35.55 | niemeyer | Zenom: You can define a default order as well, if you want |
| 22:36.03 | Zenom | how do I do that? |
| 22:37.10 | niemeyer | Zenom: Use the order_by keyword when building the ReferenceSet |
| 22:37.20 | Zenom | ah ok cool thanks |
| 22:39.46 | Zenom | http://pastie.caboo.se/117586 |
| 22:39.47 | Zenom | like that? |
| 22:43.09 | Zenom | yep that worked i had a bug somewhere else, cool :) |
| 22:53.52 | niemeyer | Ah, ok :-) |
| 22:57.50 | niemeyer | SELECT "my schema"."my table"."my.column" FROM "my schema"."my table" |
| 22:57.53 | niemeyer | Beautiful :-) |
| 23:11.41 | pyCube | schema stuff |
| 23:13.42 | niemeyer | Alright.. time for a quick review |
| 23:13.55 | niemeyer | Who's around? |
| 23:14.17 | niemeyer | radix? jkakar? oubiwann? |
| 23:14.23 | jkakar | Yo! |
| 23:14.26 | oubiwann | yo! |
| 23:14.38 | niemeyer | Would you guys have time for a quick review? |
| 23:14.42 | jkakar | Sure |
| 23:14.46 | oubiwann | sure |
| 23:14.47 | niemeyer | http://pastebin.ubuntu.com/1971/ |
| 23:15.43 | niemeyer | I've catched the "import user' |
| 23:16.01 | oubiwann | niemeyer: is there a corresponding ticket I can look at? |
| 23:16.11 | niemeyer | oubiwann: Oh, sorry for the lack of context |
| 23:16.21 | oubiwann | np :-) |
| 23:16.30 | niemeyer | oubiwann: This is about allowing schemas in __storm_table__ for PostgreSQL |
| 23:16.36 | radix | hi |
| 23:16.47 | pyCube | hey, i submitted that bug :-p |
| 23:16.48 | niemeyer | oubiwann: IOW, if someone uses __storm_table__ = "my schema.my table" |
| 23:17.03 | niemeyer | oubiwann: This should end up as "my schema"."my table" |
| 23:17.11 | niemeyer | pyCube: Woah, thanks! :-) |
| 23:17.14 | oubiwann | niemeyer: right |
| 23:17.20 | oubiwann | thanks :-) |
| 23:17.36 | niemeyer | radix: Heya! |
| 23:18.17 | niemeyer | So the patch consists of 1) Making a postgres-specific compiler for SQLToken.. and 2) Making everyone use cls_info.table instead of type.__storm_table__, as the former has the SQLToken() wrapping |
| 23:18.41 | niemeyer | Coincidently, (2) actually fixes a bug for other databases as well.. |
| 23:18.54 | niemeyer | (they were not escaping reserved keywords in table names) |
| 23:18.55 | oubiwann | nice |
| 23:19.00 | aa_ | if anyone cares, kiwi: http://async.com.br/projects/kiwi/ (which is a UI framework on top of PyGTK) has Storm integration/support for the database stuff |
| 23:19.25 | niemeyer | aa_: Oh, sweet! |
| 23:19.46 | niemeyer | I didn't know Johan had actually gone that far |
| 23:19.58 | aa_ | you might have heard of it since Kiko (of launchpad fame) was the original author |
| 23:20.06 | aa_ | niemeyer: oh, I wrote the support |
| 23:20.21 | niemeyer | aa_: Wow, that's super.. thanks! |
| 23:20.43 | aa_ | not at all, thanks for making storm really :) |
| 23:21.05 | aa_ | but kiwi is becoming Enterprisey, which can only be good |
| 23:21.20 | jkakar | niemeyer: The Delete in this line appears unused: |
| 23:21.23 | jkakar | +from storm.expr import (Union, Select, Alias, SQLRaw, State, Sequence, Like, |
| 23:21.23 | jkakar | + Delete) |
| 23:21.32 | jkakar | in tests/databases/postgres.py |
| 23:21.46 | niemeyer | jkakar: OOps.. thanks! |
| 23:23.59 | jkakar | niemeyer: I think I understand the changes. +1. |
| 23:24.12 | niemeyer | aa_: Sweet! |
| 23:24.13 | niemeyer | jkakar: Thanks! |
| 23:25.02 | jkakar | niemeyer: np |
| 23:29.42 | Zenom | niemeyer: so is the postgresql schema stuff submitted? :) |
| 23:29.59 | jkakar | I think he needs one more +1. :) |
| 23:30.15 | jkakar | niemeyer: What's that branch called, btw? |
| 23:30.56 | niemeyer | jkakar: It's not :) |
| 23:31.07 | jkakar | niemeyer: Ah, a change in trunk? |
| 23:31.16 | niemeyer | jkakar: Yeah.. just a diff for now |
| 23:31.34 | jkakar | Cool |
| 23:35.49 | gpolo | aa_: is that kiwi integration with storm somewhere on the api described on kiwi's site yet ? |
| 23:36.14 | aa_ | gpolo: patch just got in today, so I doubt it |
| 23:36.24 | gpolo | right |
| 23:38.56 | aa_ | gpolo: let me paste you what's in examples/ http://dpaste.com/24981/ |
| 23:40.04 | aa_ | that example is a full search UI |
| 23:41.37 | gpolo | ah, thank you |
| 23:41.41 | gpolo | i will give kiwi a try then ;) |
| 23:42.10 | aa_ | well, if you code pygtk, you really really should use kiwi (imo) |
| 23:42.33 | aa_ | I gave up writing my own generic stuff, and contributing to kiwi instead |
| 23:42.45 | aa_ | it has the added bonus that Johan reviews the code :) |
| 23:42.52 | gpolo | i have used pygtk a lot, but the project i was working in didn't allow to add dependencies, like kiwi |
| 23:43.17 | thumper | I really wish they wouldn't have used the name "kiwi" |
| 23:43.21 | thumper | :( |
| 23:43.40 | aa_ | thumper: I agree, it's an awful name |
| 23:43.49 | pyCube | whats wrong with it? |
| 23:43.55 | aa_ | pyCube: searchability |
| 23:44.12 | aa_ | I should say googleability |
| 23:44.52 | pyCube | hm.. googleing "kiwi python" get its at the top |
| 23:45.13 | gpolo | well, i wouldn't say it affects the "googleability" at all |
| 23:45.30 | gpolo | if a person doesn't know kiwi, it is very hard to him type "kiwi" |
| 23:45.44 | gpolo | he would search for something like pygtk framework |
| 23:47.42 | gpolo | aa_: nice example, btw |
| 23:47.56 | gpolo | you just forgot a import datetime |
| 23:48.22 | thumper | pyCube: kiwi is a small flightless native bird of New Zealand |
| 23:48.26 | aa_ | oh sorry that's the first line of the script, I missed it in the selection |
| 23:48.42 | thumper | pyCube: whereas they use the icon of a "kiwifruit" or "zespri" or "chinese gooseberry" |
| 23:52.50 | gpolo | aa_: why does it create a statusbar ? |
| 23:52.59 | gpolo | why kiwi does, that is |
| 23:53.21 | aa_ | it's the search Container framework |
| 23:54.19 | aa_ | gpolo: just don't call set_summary_label on it |
| 23:54.24 | aa_ | (and no status bar) |
| 23:55.13 | gpolo | ah I see |
| 23:55.15 | gpolo | =) |
| 23:55.31 | gpolo | i didn't know what that was doing there |