| 00:00.44 | *** join/#storm wallflower (n=wallflow@ip-205-246-113-216.pool.grokthis.net) |
| 18:43.03 | *** join/#storm jbot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
| 18:43.03 | *** topic/#storm is The Storm Python ORM - http://storm.canonical.com/ - 0.12 released! || Review branches: https://code.launchpad.net/~storm/storm/trunk/+landing-candidates |
| 19:10.29 | *** join/#storm bigdog (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
| 19:45.19 | oohlaf | hello |
| 19:46.07 | jkakar | Hello |
| 19:47.17 | oohlaf | I have a question regarding storm and pylons |
| 19:47.25 | oohlaf | I have an example at http://pastebin.com/m7f662446 |
| 19:47.44 | oohlaf | is there a nicer way to create the database connection? |
| 19:47.50 | oohlaf | than in the controller |
| 19:48.52 | oohlaf | also, if I close the connecten and let the controller return a response using the mako template, it can't list the persons |
| 19:49.03 | oohlaf | because it says "connection closed" |
| 19:49.18 | oohlaf | which seems logical, but where should I move the connection stuff? |
| 20:23.46 | therve | oohlaf: it's probably more a question related to pylons? |
| 20:23.55 | therve | oohlaf: but store.find() returns a generator |
| 20:24.05 | therve | oohlaf: if you want to query to be fired, call list() on the result |
| 20:24.17 | therve | (not really a generator, but something iterable) |
| 20:24.52 | oohlaf | ah, ok, I'll try that |
| 20:24.58 | therve | oohlaf: I would guess that pylons has some method called when your request is ending, that would be the best place to close the connection |
| 20:26.32 | oohlaf | I also saw this discussion: https://lists.ubuntu.com/archives/storm/2007-August/000264.html |
| 20:26.51 | oohlaf | which talked about not reusing a store |
| 20:27.20 | oohlaf | so I though maybe best to put it in the controller so it's only called once per request |
| 20:28.40 | therve | no, the problem there is that the connection is reused |
| 20:30.05 | therve | or maybe not? |
| 20:30.56 | oohlaf | but it also seems wrong to me to add storm init as a middleware component, because that adds a dependency between my app and the middleware, so the middleware isn't pluggable anymore |
| 20:32.46 | therve | you could add a layer somewhere, that's not really a problem |
| 20:33.22 | oohlaf | Could make a StormController which inherits from BaseController to create a store |
| 20:33.39 | oohlaf | and let my PersonController inherit from that |
| 20:34.08 | oohlaf | 'ResultSet' object has no attribute 'list' |
| 20:34.35 | therve | oohlaf: list(result), not result.list() |
| 20:34.42 | oohlaf | oh |
| 20:35.26 | oohlaf | thanks, it works now |
| 20:35.56 | oohlaf | I'll think a bit about the init stuff |
| 20:36.21 | oohlaf | is also new to the whole pylons framework |
| 21:29.42 | rreis | niemeyer, just fixed that issue. |
| 21:30.15 | rreis | niemeyer, this is the reference now. ReferenceSet((cidade_id,stats_id),(DadosCidade.cidade_id, DadosCidade.stats_id)) |
| 21:33.31 | jkakar | Woah, Portuguese variable names rock. Now we just need UTF8-by-default encodings in .py files. :) |
| 21:35.21 | fcorrea_ | jkakar, one our developers wouldn't be able to understand English ones ;) |
| 21:35.30 | fcorrea_ | And that developer is rreis |
| 21:36.47 | jkakar | fcorrea_: Yeah, makes sense. It's just interesting to read the example, know that 'cidade' means city and then try to figure out what 'dados' means from the context. :) |
| 21:37.03 | rreis | hehehe |
| 21:37.05 | jkakar | fcorrea_: I'm not a Portuguese speaker which makes it even more intersting. :) |
| 21:37.14 | rreis | jkakar, dados = data |
| 21:37.19 | jkakar | rreis: Ah! |
| 21:37.25 | jkakar | rreis: Thanks. :) |
| 21:37.28 | rreis | ;) |
| 21:37.32 | fcorrea_ | rreis, please fix that man!! |
| 21:38.05 | fcorrea_ | IMMEDIATELY! |
| 21:39.17 | jkakar | Heh |
| 21:41.29 | rreis | fcorrea_: yes Sr! |
| 22:03.38 | oohlaf | I'm reading https://storm.canonical.com/Manual#Managing%20stores |
| 22:04.01 | oohlaf | Does this mean I should only create a Store object whenever I want to actually do a database operation |
| 22:04.53 | oohlaf | Like I did in http://pastebin.com/m30a0a0a |
| 22:05.32 | fcorrea_ | oohloaf, I don't know how singletons are implemented in pylons, but as a reference you could take a look at the z3 utility for example |
| 22:05.45 | fcorrea_ | Well, actually I think it is going to make things harder |
| 22:08.44 | oohlaf | fcorrea_: do you mean zstorm.py? |
| 22:15.08 | fcorrea_ | oohlaf, yep |
| 22:15.50 | fcorrea_ | oohlaf, I know it is a bit hairry and z3 oriented but you get the idea |
| 22:16.50 | fcorrea_ | oohlaf, or you just ask the pylons guys how to write an utility that will always returns the same object and wrap storm around it |
| 22:20.28 | fcorrea_ | OR you can use the zstorm code as a base for your utility by removing zope specific code. Then you just install zope.component and you can use zstorm in your code as in from zope.component import queryUtility; store = queryUtility(IZStorm).get('named_store') |
| 22:20.47 | fcorrea_ | I mean, it is still ugly but you are now provided with some ideas :) |
| 22:22.32 | oohlaf | ehm, let me grasp the idea first |
| 22:22.46 | oohlaf | looking at the zstorm stuff |
| 22:23.25 | oohlaf | So a storemanager should be a singleton within pylons |
| 22:23.35 | oohlaf | across all threads |
| 22:23.47 | fcorrea_ | I'd say so |
| 22:24.11 | jkakar | oohlaf: I think what you want, at least conceptually, is one Store/thread that is committed or rolled back at the end of each request. |
| 22:24.38 | jkakar | oohlaf: Establishing a connection is a somewhat heavyweight operation; you don't really want to do that for each request. |
| 22:26.59 | fcorrea_ | oohlaf, for the commit story, you can use the WSGI middleware from repoze.org. Namely repoze.tm (transaction manager). So by using it, you could find the threaded store and commit/rollback it from there |
| 22:27.43 | fcorrea_ | But this that's another story |
| 22:28.41 | fcorrea_ | Sorry for the storm of ideas :-P |
| 22:29.31 | oohlaf | hehe |
| 22:30.11 | oohlaf | so is everyone here using storm with zope3? |
| 22:31.19 | fcorrea_ | oohlaf, \o_ |
| 22:32.12 | jkakar | oohlaf: We're using it here on Landscape, as are the Launchpad guys. |
| 22:32.48 | jkakar | oohlaf: But we definitely want Storm to be usable *everywhere*, so I'm glad you're diving into Pylons and taking the time to integrate Storm. |
| 22:33.35 | oohlaf | hehe, well, I'm having a look, not promissing anything yet ;) |
| 22:33.43 | fcorrea_ | oohlaf, have you tried this middlestorm package? |
| 22:33.56 | oohlaf | no I havent yet, I read the mails though |
| 22:35.10 | fcorrea_ | oohlaf, http://snippets.dzone.com/user/sevkin/tag/pylons |
| 22:36.05 | fcorrea_ | The decorator idea for the app sounds quite cool |
| 22:37.33 | oohlaf | https://lists.ubuntu.com/archives/storm/2007-August/000264.html |
| 22:38.53 | jkakar | oohlaf: Yeah. I don't know much about Pylons but that middlestorm thing appears to be suboptimal. |
| 22:39.21 | jkakar | """ |
| 22:39.25 | fcorrea_ | oohlaf, http://pypi.python.org/pypi/middlestorm/0.7 |
| 22:39.25 | jkakar | <PROTECTED> |
| 22:39.25 | jkakar | <PROTECTED> |
| 22:39.26 | jkakar | """ |
| 22:39.30 | jkakar | I guess that's the key point. |
| 22:39.35 | fcorrea_ | seems to be more up to date |
| 22:39.55 | jkakar | Though, it looks like that's an option, not a hard-coded decision. |
| 22:48.24 | oohlaf | not sure if it allows two connections to different databases (sqlite files) though |
| 22:48.55 | oohlaf | seems to bind one connection per application |
| 22:49.09 | *** join/#storm thumper (n=tim@canonical/launchpad/thumper) |
| 22:55.10 | oohlaf | is off to bed |
| 22:55.13 | oohlaf | bye bye |
| 22:56.36 | jkakar | oohlaf: Take care! |
| 23:08.18 | *** join/#storm reacocard (n=reacocar@rccy-06-1010.dsl.iowatelecom.net) |
| 23:23.37 | *** join/#storm jml (n=jml@li2-200.members.linode.com) |