| 00:00.15 | *** join/#storm wallflower (n=wallflow@ip-205-246-113-216.pool.grokthis.net) |
| 00:00.17 | vinsci | but right now, I'm curious to see even an unsupported way :) |
| 00:41.28 | niemeyer | vinsci: The tutorial has nothing to do with this, as I think was clear from the message in the mailing list |
| 00:42.09 | niemeyer | vinsci: There isn't a supported way to do this, because we couldn't find a way to implement it that would look nice and maintainable |
| 00:42.44 | niemeyer | vinsci: If you look at the project history, you'll see that we've removed some code which was precisely related to this, specifically because we didn't like the end code produced when using the systme. |
| 00:43.16 | niemeyer | vinsci: The way we've used it, was to create classes reflecting the reality of the database. |
| 00:43.55 | niemeyer | vinsci: We have quite complex code mapping "inheritance" (in the database, not in code) with Storm in Landscape. |
| 00:45.09 | niemeyer | vinsci: If you can't use Storm without it, I recommend looking at SQLAlchemy or other projects that support it. |
| 00:46.09 | niemeyer | vinsci: We won't introduce anything fancy just for the sake of it, unless we can prove good and maintainable code can be produced out of it. |
| 00:46.57 | vinsci | niemeyer, ok, Landscape seems to be proprietary stuff, so I can't look at that code |
| 00:47.21 | niemeyer | vinsci: Landscape is partly proprietary "stuff", yes |
| 00:48.06 | niemeyer | vinsci: We don't do anything supernatural in Landscape, though |
| 00:48.49 | niemeyer | vinsci: We have an Operation class, with a type field, and we have OperationInfo classes (and subclasses) which are defined in N tables with specific information. |
| 00:49.20 | niemeyer | vinsci: Due to the clarity of the "obvious" implementation, we are able to maintain it much more easily. |
| 00:49.48 | niemeyer | vinsci: and removed the fancy adaptation mechanism before making Storm public, because we didn't want to maintain something we didn't like. |
| 00:50.10 | niemeyer | vinsci: You can still find the implementation in the history, if you're curious. |
| 00:50.32 | vinsci | niemeyer, using bazaar then, I guess |
| 00:50.38 | niemeyer | vinsci: Precisely |
| 00:53.36 | niemeyer | vinsci: Notice that when I say that the code tends to be hard to maintain, I'm not talking about the Storm implementation, I'm talking about the use of the feature. |
| 00:58.20 | vinsci | bazaar 1.4.2 any good? I'm on Etch... |
| 00:59.16 | vinsci | hmm only 1.2 on bazaar-vcs.org...? |
| 00:59.43 | niemeyer | vinsci: Yep, that's the last version |
| 01:09.59 | vinsci | ah, the Etch version is really 0.11 for bzr (was looking at the bazaar pkg earlier) |
| 01:15.58 | jamesh | vinsci: 1.4.2 is probably bzr's predecessor |
| 01:16.10 | vinsci | jamesh, yes, it is |
| 01:28.42 | vinsci | niemeyer, do you remember when that functionality was taken out, or even better, the revision number? |
| 01:29.37 | niemeyer | vinsci: In revision 112 |
| 01:30.16 | vinsci | thanks, niemeyer |
| 01:30.37 | niemeyer | vinsci: No problem |
| 06:23.28 | *** join/#storm jamesh (n=james@canonical/launchpad/jamesh) [NETSPLIT VICTIM] |
| 06:23.28 | *** join/#storm bigdog (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) [NETSPLIT VICTIM] |
| 06:23.28 | *** join/#storm jkakar (n=jkakar@c-67-169-182-99.hsd1.ca.comcast.net) [NETSPLIT VICTIM] |
| 06:39.47 | *** join/#storm jukart (n=jukart@lsfw01.lovelysystems.com) |
| 07:57.26 | *** join/#storm goschtl (n=goschtl@p5B0BDFDB.dip.t-dialin.net) |
| 08:32.32 | *** join/#storm mcella (n=michele@ip-179-143.sn2.eutelia.it) |
| 12:26.21 | *** join/#storm niemeyer (n=niemeyer@200-103-245-169.ctame705.dsl.brasiltelecom.net.br) |
| 13:27.34 | goschtl | niemeyer: if I use this http://paste.lisp.org/display/57359. Is it important to make the transaction.commit() or does zope is responsible for commiting? |
| 13:29.15 | niemeyer | goschtl: Zope is responsible for committing if the request succeeded |
| 13:29.34 | goschtl | niemeyer: ok thx |
| 13:30.47 | jamesh | hi niemeyer |
| 13:57.10 | niemeyer | jamesh: Hey James |
| 13:57.45 | jamesh | niemeyer: I ran into https://bugs.edge.launchpad.net/storm/+bug/202081 today |
| 13:58.08 | jamesh | another missing feature in the sqlobject compatibility layer, which I'm not sure how to handle even with native storm |
| 14:00.18 | jamesh | sometimes postgres isn't as smart as I'd like |
| 14:01.14 | niemeyer | Let me see |
| 14:06.52 | niemeyer | jamesh: Yeah, tricky indeed |
| 14:07.43 | niemeyer | jamesh: I think (2) is somewhat inline with a feature I'd like to add anyway |
| 14:08.06 | niemeyer | jamesh: I'll include that in the investigations I'll have to do next week about prejoins |
| 14:08.48 | niemeyer | jamesh: I've spiked something about that feature I'd like to add already, but didn't get too far.. |
| 14:08.53 | niemeyer | jamesh: (holidays, etc :-) |
| 14:09.23 | niemeyer | jamesh: Basically, I'd like to allow people to use any kind of expression in a find() call, rather than just types |
| 14:09.26 | niemeyer | jamesh: Even mixed |
| 14:09.33 | jamesh | niemeyer: there is only about 3 cases where we use it in Launchpad, and the expression is usually rank(fti, ftq('search string')) |
| 14:09.52 | niemeyer | jamesh: So that doing store.find((MyClass, Count())), actually works, for instance |
| 14:10.26 | niemeyer | jamesh: Implementing that should fix (or rather, workaround) the issue you have there |
| 14:10.50 | niemeyer | jamesh: This is also the basis for generic group_by support |
| 14:11.05 | jamesh | niemeyer: in all of these cases, I don't really care about the value of the column: it is only used for ordering based on the full text index |
| 14:11.11 | jamesh | cool. |
| 14:14.32 | niemeyer | jamesh: We may also be able to do some magic to introduce the value artificially in the select statement. We already do quite some mangling on order by statements, for *all* databases (thanks to how "standardized" it is). |
| 14:15.28 | niemeyer | jamesh: That may have future consequences we can't predict now, though, so if we have so few call sites there, it might be safer to just stick the value, and use the time to implement some generally useful features. |
| 14:15.51 | jamesh | niemeyer: yeah. It didn't look too difficult to add a few extra columns to the Select() instance created by Result._get_select() |
| 14:16.47 | jamesh | of course, I wanted to get your opinion in case it'd break some brilliant new feature you've got up your sleeve :) |
| 15:24.56 | *** join/#storm licorna (n=rvalin@206.57.107.242) |
| 15:30.25 | *** join/#storm marianom (n=marianom@ubuntu/member/marianom) |
| 16:08.06 | *** join/#storm bigdog (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
| 17:19.39 | *** join/#storm ubot3 (n=ubot3@unaffiliated/nalioth/bot/ubot3) |
| 17:56.28 | *** join/#storm bigdo1 (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
| 19:08.06 | *** join/#storm ubot3 (n=ubot3@unaffiliated/nalioth/bot/ubot3) |
| 19:18.51 | *** join/#storm jukart (n=jukart@85-124-221-45.static.xdsl-line.inode.at) |
| 19:19.35 | *** join/#storm jamesh_ (n=james@canonical/launchpad/jamesh) |
| 20:42.17 | *** join/#storm jkakar (n=jkakar@c-67-169-182-99.hsd1.ca.comcast.net) |
| 20:55.54 | *** join/#storm Brend (n=brendonh@218-170-229-150.dynamic.hinet.net) |