| 00:21.26 | tjs | radix: |
| 00:21.33 | tjs | setup.py |
| 00:21.46 | tjs | seems to be missing :) |
| 00:27.38 | jkakar | tjs: It is. Apparently oubiwann has posted a patch to add something like that; it hasn't made it the list yet. |
| 00:27.58 | tjs | cool |
| 00:28.01 | oubiwann | jkakar: yeah, I think it's being held by mailman |
| 00:28.24 | tjs | so how open is the development? |
| 00:28.25 | jkakar | oubiwann: Yeah, I figured new-list-configuration-fun was to blame. :) |
| 00:28.31 | oubiwann | heh |
| 00:28.42 | jkakar | tjs: It's open. |
| 00:28.57 | tjs | will non-canonical contributers get commit access at some point? |
| 00:29.03 | jkakar | tjs: However, you can expect a UQDS-like review cycle before anything will be accepted. |
| 00:29.15 | tjs | thats fair |
| 00:29.22 | jkakar | tjs: I don't know what the plans are around that; however, it's hosted on launchpad. |
| 00:30.16 | jkakar | tjs: You can always branch from http://bazaar.launchpad.net/~storm/storm/trunk to implement your changes. |
| 00:30.34 | *** join/#storm jml (n=jml@203-113-250-169-static.TAS.netspace.net.au) |
| 00:30.36 | jkakar | tjs: Because we're using bzr your new branch will be completely functional. |
| 00:30.39 | tjs | heya jml |
| 00:30.58 | jkakar | tjs: You can push branches directly up to launchpad and they'll appear on the storm product page. |
| 00:31.19 | tjs | cool |
| 00:31.32 | jkakar | tjs: So, in some ways, given the tools we're using having commit access to trunk is less exciting than it is in a CVS/SVN style environment. |
| 00:32.10 | jkakar | tjs: niemeyer is the primary author of Storm and he's a very reasonable guy. I wouldn't anticipate problems with getting features in; they will have to go through the review process, as mentioned. |
| 00:32.11 | jml | Welcome to the joy of Launchpad / Bazaar |
| 00:32.17 | tjs | the zope3 storm glue radix was talking about |
| 00:32.22 | jkakar | jml: It's *SO* awesome. |
| 00:32.25 | tjs | will that be part of the storm package? |
| 00:32.32 | tjs | or another thing? |
| 00:32.45 | jkakar | tjs: It's very small. I'll send a message just now to our manager about it. |
| 00:32.45 | jml | jkakar: :) |
| 00:32.50 | jkakar | tjs: Likely another thing. |
| 00:32.57 | tjs | jkakar: that would be fantastic |
| 00:32.59 | jml | jkakar: noticed any improvements using bzr+ssh for storm? |
| 00:33.07 | jkakar | jkakar: With LP? |
| 00:33.49 | jml | jkakar: yeah |
| 00:33.49 | jml | (I assume you weren't talking to yourself) |
| 00:33.56 | jkakar | jml: I've generally noticed that since 0.17 came out bzr+ssh works reliably. In the past I found myself falling back to sftp for certain operations (like 'bzr update'). |
| 00:34.23 | jkakar | jml: I tend not to talk to myself, so yeah... ;) |
| 00:36.56 | *** join/#storm bogdano (n=bogdano@201-15-250-176.ctame704.dsl.brasiltelecom.net.br) |
| 00:38.45 | jkakar | tjs: I've just sent a message mentioning that there have been requests for the Zope integration code to be opened. We'll see what happens now. :) |
| 00:39.02 | tjs | jkakar: thanks :) |
| 00:39.07 | jkakar | tjs: np. |
| 00:49.24 | tjs | riddle me this |
| 00:49.37 | tjs | I create a class, and an in-mem db |
| 00:49.47 | tjs | I dont create a table |
| 00:50.10 | tjs | I can add an object from this class to a store, I can flush the store, with no complaint about a missing table |
| 00:51.28 | tjs | I can store.commit() without complaint also |
| 00:53.55 | jml | tjs: c'mon, that's just the sort of riddle that should send you diving into the source, documentation pants at the ready. |
| 00:54.13 | jkakar | tjs: Ouch. :) |
| 00:54.20 | tjs | jml: aye, I started diving about a minute ago ;) |
| 00:55.10 | tjs | why the localst.py indirection ? |
| 00:55.16 | tjs | locals.py |
| 01:05.44 | tjs | radix: when are you going to be in AU next? |
| 01:06.13 | tjs | they should run one of those canonical get-togethers in Melbourne so we can catch up again :) |
| 01:23.03 | *** join/#storm johan (n=jdahlin@201-42-94-52.dsl.telesp.net.br) |
| 01:27.37 | tjs | is the list archive restricted to showing posts after the date you sign up? |
| 01:27.49 | tjs | or is the mailing list totally new? |
| 01:44.28 | radix | tjs: there were only a few posts before we opened the list |
| 01:48.36 | *** join/#storm jkakar (n=jkakar@c-24-21-131-142.hsd1.mn.comcast.net) |
| 01:51.45 | *** join/#storm creiht (n=cthier@cpe-67-11-141-184.satx.res.rr.com) |
| 01:54.56 | tjs | woot |
| 01:55.17 | tjs | I have a semi working upgraders registry for storm classes |
| 01:56.05 | tjs | using __storm_loaded__ |
| 02:08.54 | radix | hooray :) |
| 02:10.04 | tjs | radix: is it possible to create complex SQL() expressions for optimising expensive queries, and have the results munged into objects? |
| 02:10.59 | tjs | or partial objects with lazy-lookup of attributes missing from the result set? |
| 02:22.36 | radix | wait, oubiwann's patch didn't make it to the list? |
| 02:22.41 | radix | I guess I didn't notice since he Cc'd me |
| 02:25.16 | radix | tjs: there's generally no need to use SQL() for optimizing queries |
| 02:25.38 | radix | tjs: the find() syntax is isomorphic with actual SQL |
| 02:25.58 | radix | the only time you really need to fall back to strings of SQL is when there's some piece of syntax which Storm does not yet support |
| 02:26.57 | radix | and as for partial objects, Storm doesn't support that but that's unlikely to be a win. We *do* lazy-load References and ReferenceSets, which is the really useful thing. |
| 02:27.49 | radix | oh, it appears oubiwann only sent the patch to me. |
| 02:27.52 | radix | not the list |
| 02:31.26 | *** join/#storm jml_ (n=jml@ppp121-44-217-216.lns1.hba1.internode.on.net) |
| 02:32.14 | oubiwann | radix: doh! what was I thinking? I mean you're special and all... but I really did mean to send that to the list |
| 02:33.12 | *** join/#storm jkakar (n=jkakar@c-24-21-131-142.hsd1.or.comcast.net) |
| 02:34.37 | oubiwann | radix: ah, I hit "reply |
| 02:34.50 | oubiwann | and the list isn't set up to reply to list, just individual |
| 02:35.05 | oubiwann | just sent it again |
| 02:35.50 | radix | oubiwann: :) |
| 02:35.56 | oubiwann | in fact, it looks like most of my sends to the list didn't make it |
| 02:36.07 | oubiwann | though barry warsaw and I had a nice exchange :-) |
| 02:36.10 | radix | oubiwann: oops :) |
| 02:36.13 | oubiwann | hehe |
| 02:36.24 | radix | oubiwann: what do you think about falling back to distutils when setuptools is unavailable? |
| 02:36.30 | oubiwann | are you a list admin? can I talk you into changing the reply behavior? |
| 02:36.37 | radix | no, I'm not |
| 02:36.42 | oubiwann | radix: sure, I think that's fine |
| 02:37.12 | oubiwann | radix: you mean ditch ez_setup and do a try block, right? |
| 02:37.14 | radix | in other words, not using ez_setup and instead just trying to import setup from setuptools, and if it fails, import setup from distutils |
| 02:37.18 | radix | yes |
| 02:37.30 | oubiwann | sure, I'll do that right now |
| 02:37.40 | radix | partially because I hate setuptools and also because I've actually seen situations where people are unable to install software because a web site is down or something |
| 02:37.59 | oubiwann | heh |
| 02:38.19 | oubiwann | well, setuptools may be a pita sometimes, but it's all we've got for now |
| 02:38.31 | oubiwann | I've been learning to live with it and even like it now |
| 02:39.05 | radix | I'm doing already with distutils :P |
| 02:39.21 | radix | I can understand e.g. windows and mac people wanting eggs, so I'm happy to let it in |
| 02:39.28 | radix | s/already/alright/ |
| 02:40.54 | radix | it's probably silly, don't envy too much :) |
| 02:40.58 | oubiwann | heh |
| 02:41.32 | oubiwann | I'm getting ready to head out to an Indian reservation for sundance, so I guess I've got plenty of adventure ahead of me :-) |
| 02:42.45 | radix | man, now _that_ is cool :) |
| 02:42.59 | oubiwann | :-) |
| 02:43.55 | radix | I guess that's what you're heading out of town for a week for |
| 02:44.12 | radix | man, busy life |
| 02:45.54 | oubiwann | heh |
| 02:45.55 | oubiwann | yup |
| 02:46.03 | oubiwann | it's been one truly nutty summer |
| 02:46.16 | oubiwann | I'm so looking forward to fall, just so the madness will end |
| 02:46.28 | oubiwann | I just send the new bzr diff |
| 02:46.50 | oubiwann | that's my last act for a while -- see you in a week |
| 02:47.32 | jml | oubiwann: ciao |
| 02:47.48 | oubiwann | jml: cya man |
| 02:47.58 | oubiwann | jml: also "hi!" it's been a while! |
| 02:48.24 | jml | :) |
| 05:36.37 | *** join/#storm niemeyer (i=niemeyer@conference/europython/x-72046f6e682c575e) |
| 06:01.13 | *** join/#storm tjs (n=tjs@203.206.162.25) |
| 06:17.06 | *** join/#storm dialtone (i=dialtone@conference/europython/x-d4141e9e671411ee) |
| 06:20.09 | *** join/#storm niemeyer (i=niemeyer@conference/europython/x-e7d477d09362975d) |
| 08:17.19 | *** join/#storm dialtone (i=dialtone@conference/europython/x-c102e842de8d79ae) |
| 08:23.00 | *** join/#storm dialtone (i=dialtone@conference/europython/x-011dedfc079b874f) |
| 08:34.23 | *** join/#storm apoirier (n=kvirc@LAubervilliers-151-11-27-221.w193-251.abo.wanadoo.fr) |
| 09:53.54 | *** join/#storm dialtone (i=dialtone@conference/europython/x-2c9f378676205afc) |
| 11:13.08 | *** join/#storm statik (n=emurphy@canonical/launchpad/statik) |
| 12:12.17 | *** join/#storm bac (n=bac@canonical/launchpad/bac) |
| 13:11.54 | *** join/#storm jmjones (n=jmjones@adsl-074-184-006-221.sip.asm.bellsouth.net) |
| 14:11.32 | *** part/#storm jmjones (n=jmjones@adsl-074-184-006-221.sip.asm.bellsouth.net) |
| 14:11.59 | *** join/#storm jmjones (n=jmjones@adsl-074-184-006-221.sip.asm.bellsouth.net) |
| 14:12.16 | *** join/#storm bigdo1 (n=scmikes@49-66-14-216-arpa.cust.cinci.current.net) |
| 14:15.29 | statik | did the tutorial get added to the source tree yet? |
| 14:16.59 | dialtone | my god... bazaar is the worst thing in the world... please make it fast :( |
| 14:17.38 | dialtone | (I know it's not exactly the right channel) |
| 14:17.59 | statik | dialtone: which version are you using? Are you talking about the speed when branching storm from launchpad? |
| 14:19.23 | dialtone | I just downloaded latest stable |
| 14:19.34 | dialtone | and I'm trying to branch zoocampr |
| 14:19.47 | dialtone | I started branching more than an hour ago |
| 14:19.54 | dialtone | and it has yet to finish :( |
| 14:21.06 | dialtone | finally |
| 14:21.10 | statik | dialtone: I don't know about a zoocampr project, are you branching over the smart server? |
| 14:21.15 | dialtone | from 16.13 to 17.20 just for the branch |
| 14:21.29 | dialtone | I'm just running: |
| 14:21.37 | dialtone | bzr branch http://repo.spacepants.org/zookeepr/mainline zookeepr |
| 14:21.56 | dialtone | I doubt the server can be considered that smart |
| 14:22.30 | statik | I know there have been some very recent developments with the bazaar smartserver that make initial branching over the network MUCH faster |
| 14:23.07 | dialtone | MUCH would be even better |
| 14:23.17 | statik | anyhow, if you are involved with spacepants.org, the folks on #bzr can probably help you set up the smartserver |
| 14:24.07 | dialtone | well, it's just that I needed to checkout this project, but if it always takes over an hour to checkout 400 revisions... |
| 14:24.48 | statik | dialtone: once you have the initial copy, you can always branch from that, and it should be pretty quick. set up a shared-repo, and it will be lightning fast |
| 14:25.13 | dialtone | yes sure but the problem is still there |
| 14:30.33 | statik | radix: take pity on me and teach me how to connect storm to multiple databases. the tests all seem to use a single DB |
| 14:31.18 | *** join/#storm bigdo2 (n=scmikes@49-66-14-216-arpa.cust.cinci.current.net) |
| 14:33.50 | radix | statik: just create two Store objects :) |
| 14:34.08 | radix | (pointing at two different database objects, of course) |
| 14:34.40 | radix | statik: btw tests/tutorial.txt is the same as the one at http://storm.canonical.com/Tutorial |
| 14:34.58 | radix | oh, I guess you knew that and were specifically looking for it in the source |
| 14:35.22 | statik | radix: thanks! i was looking for something more complicated and missed the obvious |
| 14:35.49 | statik | is there any built in support for "sharding" data between multiple DBs, or do you do that manually at the app level? |
| 14:36.23 | radix | statik: we do it at the app level |
| 14:38.04 | statik | radix: I see. are you just keeping different tables in different stores, or do you have any giant tables which you partition across different stores? |
| 14:38.29 | radix | statik: our app does have the same kinds of objects in different databases |
| 14:38.40 | radix | statik: there's also cases where certain kinds of objects are in their own special database |
| 14:39.02 | radix | statik: basically you have to figure out what the point of scaling is |
| 14:39.20 | radix | statik: per-user, per-organization, per-something-else |
| 14:40.46 | radix | if you decide to scale per-user, for example, you'll add some sort of identifier to the 'user' table to say which database all its related objects are in, and then any time you want to look up an object related to that user, you find the store for the database it's in and load the object |
| 14:42.06 | statik | cool, that confirms what I was imagining. there you have to decide ahead of time how the data will be partitioned. I want to do arbitrary partitioning based on real world business relationships which will change over time (and the code should not have to change), so I guess I'll need to build a separate layer to do the mapping between stores. I've heard people advocate using memcached for doing partition mapping lookup stuff, but haven't ever |
| 14:42.07 | statik | used it myself |
| 14:43.26 | radix | hmm |
| 14:43.30 | radix | that's interesting |
| 14:43.39 | radix | statik: but isn't your scaling point then "business relationship"? :) |
| 14:44.03 | dialtone | radix: apparently gustavo is going to have a sprint here, but unfortunately I won't be able to partecipate |
| 14:44.11 | dialtone | push for async integration pleeeeease |
| 14:44.20 | radix | dialtone: I really don't know what that means |
| 14:44.26 | radix | dialtone: it's not as simple as it sounds :) |
| 14:45.13 | statik | radix: I made a slight simplification. I'm not partitioning to scale, I'm partitioning for data privacy reasons, so I want to allow arbitrary movement of objects between different stores |
| 14:45.22 | radix | statik: huh, interesting |
| 14:45.37 | radix | statik: so yeah, I was just wondering about moving objects |
| 14:45.42 | statik | radix: this is why I was interested in using UUID as PK |
| 14:45.51 | radix | statik: ah yes! |
| 14:46.08 | radix | We'll have to check to make sure that moving an object from one store to another is easy with storm |
| 14:46.41 | radix | I *imagine* it's as simple as store1.remove(obj); store2.add(obj) |
| 14:46.56 | *** join/#storm michelp (n=michelp@69-30-72-119.dq1sf.easystreet.com) |
| 14:47.00 | statik | radix: awesome. this is something I hope to be able to play with soon, I'll let you know how it goes |
| 14:47.08 | *** join/#storm niemeyer (i=niemeyer@conference/europython/x-5005b7d636bc926c) |
| 14:47.10 | radix | statik: cool, good luck |
| 14:47.48 | statik | radix: thanks! figuring out how to do the move transactionally will be interesting |
| 14:48.07 | radix | ohh yeah, cross-store transactions |
| 14:48.10 | radix | always a fun thing |
| 14:48.13 | *** join/#storm bigdo1 (n=scmikes@49-66-14-216-arpa.cust.cinci.current.net) |
| 14:48.41 | niemeyer | Hey everyone |
| 14:49.00 | jmjones | hi someone :-) |
| 14:49.18 | statik | hey there niemeyer |
| 14:49.22 | radix | jbot: logs |
| 14:49.22 | jbot | [logs] apt/ibot/infobot/jbot/purl all log daily to http://ibot.rikers.org/<channelname>/ where channelname is html encoded ie: %23debian | lines that start with a space are not shown | some channels have stats at http://ibot.rikers.org/stats/<channelname>.html.gz |
| 14:50.02 | radix | jmjones: Hi :_) |
| 14:50.21 | *** mode/#storm [+o radix] by ChanServ |
| 14:50.25 | *** mode/#storm [-o jbot] by radix |
| 14:50.27 | *** mode/#storm [-o radix] by radix |
| 14:50.35 | radix | now it's less scary |
| 14:50.38 | jmjones | /who radix |
| 14:50.49 | radix | jmjones: maybe "/whois" :-) |
| 14:50.54 | jmjones | sorry - trying to figure out how i know radix |
| 14:51.07 | jmjones | yeah - better - hi radix |
| 14:51.24 | jmjones | trying to see if you were on #python |
| 14:51.50 | radix | unlikely, probably #twisted :) |
| 14:51.57 | jmjones | yeah - that's what i was just thinking |
| 14:54.51 | niemeyer | radix is famous.. I've seen his name at least twice at EuroPython |
| 14:55.10 | jmjones | niemeyer: you're no slouch yourself... |
| 14:55.13 | radix | oh crap, they've found out about me |
| 14:55.44 | jmjones | your name (and storm) has been popping up a lot lately it seems |
| 14:56.48 | radix | niemeyer: so who mentioned me, some Twisted guys? |
| 14:58.07 | niemeyer | jmjones: I just go to conferences to show up.. radix is the guy who actually codes |
| 14:58.31 | radix | snrk ;P |
| 14:58.55 | niemeyer | radix: Storm's talk, and Michael Hudson just mentioned it again |
| 14:59.02 | niemeyer | radix: With twisted context |
| 14:59.03 | jmjones | :-) i would ask how i get a gig like that, but i think i like coding more. conferences are fun, though. |
| 14:59.13 | radix | niemeyer: did I tell you that like ten minutes after I posted my blog post about storm, someone sent me a private email asking to give a talk on storm at the cambridge python meetup? |
| 14:59.34 | niemeyer | Woah! That's very cool! |
| 15:00.23 | radix | yeah, I'll proabbly some of your slides :) |
| 15:00.42 | niemeyer | Dudes! I've got a conf call in half an hour (not about Storm).. I have to find a phone.. |
| 15:01.02 | radix | just ask one of your thousands of adoring fans :) |
| 15:01.18 | niemeyer | I'll try to post a mail about the development process late today, and push a branch for review |
| 15:01.53 | radix | niemeyer: SPEAKING of which, you did not put oubiwann's patch through the full review process! :) |
| 15:02.03 | niemeyer | radix: Ah, that was [trivial] :-) |
| 15:02.13 | radix | hehe, fair enough :) |
| 15:02.27 | niemeyer | But I did forget to tag it.. :-( |
| 15:02.32 | niemeyer | Anyway.. back later! |
| 15:02.34 | radix | later |
| 15:05.01 | *** join/#storm bigdo1 (n=scmikes@49-66-14-216-arpa.cust.cinci.current.net) |
| 15:15.09 | *** join/#storm dialtone (i=dialtone@conference/europython/x-7e5352c51952b54a) |
| 15:19.40 | *** join/#storm niemeyer (i=niemeyer@conference/europython/x-51eca801b294175b) |
| 15:57.12 | *** join/#storm creiht (n=cthier@64.39.1.11) |
| 16:05.17 | *** join/#storm michelp (n=michelp@72.11.116.6) |
| 16:07.07 | *** join/#storm rbriski (i=rbriski@nat/yahoo/x-6b58e66343fcdced) |
| 16:11.38 | *** join/#storm jkakar (n=jkakar@72.11.116.6) |
| 16:13.21 | *** join/#storm jkakar (n=jkakar@72.11.116.6) |
| 16:23.31 | *** join/#storm bogdano (n=bogdano@201-15-250-176.ctame704.dsl.brasiltelecom.net.br) |
| 17:08.08 | *** join/#storm bigdo1 (n=scmikes@49-66-14-216-arpa.cust.cinci.current.net) |
| 17:44.03 | *** join/#storm michelp (n=michelp@72.11.116.6) |
| 18:02.58 | *** join/#storm rafael (n=rafael@moinmoin/fan/rafael) |
| 18:03.08 | rafael | hoi |
| 18:06.03 | *** join/#storm bigdo2 (n=scmikes@49-66-14-216-arpa.cust.cinci.current.net) |
| 18:06.19 | radix | rafael: Good Afternoon |
| 18:08.19 | rafael | i'm just working through the tutorial - its sooooo great (i didn't unsterstand sqlalchemy), but why is the argument called "noresult" and not "result" ? |
| 18:11.02 | radix | rafael: you mean why is it "noresult=True" and not "result=False"? |
| 18:11.11 | rafael | radix: yes |
| 18:11.18 | radix | rafael: shrug. does it really matter? :) |
| 18:12.22 | rafael | not really *g* but i got a bit confused about it |
| 18:12.30 | radix | rafael: it should be a pretty rare thing to use |
| 18:14.43 | radix | rafael: anyway, I'm glad you like it |
| 18:15.00 | rafael | its very simple i think |
| 18:16.37 | rafael | if i can persuade my friend of it, our new project runs with it |
| 18:16.50 | rafael | he is a fan from dejavu.. i don't know it |
| 18:17.10 | radix | good luck :) we're happy to help with any questions you have |
| 18:18.02 | *** part/#storm jdahlin (n=jdahlin@200-171-140-32.dsl.telesp.net.br) |
| 18:19.09 | rafael | the whole launchpad system uses it, right? |
| 18:20.53 | radix | rafael: launchpad doesn't yet use it in production, but it will soon. |
| 18:21.23 | rafael | cool, so then it probably will get more features.. |
| 18:21.38 | radix | rafael: well, it's already gotten many of the features. |
| 18:21.43 | radix | rafael: the SQLObject emulation layer, especially |
| 18:22.02 | rafael | SQLObject emulation layer? whats that? |
| 18:22.13 | radix | storm.sqlobject |
| 18:22.40 | radix | It's a layer on top of Storm which allows you to replace SQLObject. |
| 18:22.47 | radix | it emulates the SQLObject API with Storm underneath. |
| 18:25.53 | rafael | whats a sql object *manager*? |
| 18:25.54 | radix | rafael: oh. it's one of the most popular Python ORMs. |
| 18:26.24 | rafael | something like SQLAlchemy? |
| 18:26.27 | radix | yes. |
| 18:26.35 | radix | but it's very simple. |
| 18:26.51 | rafael | ah, and with storm you can use SQLObject behind the scenes? |
| 18:27.03 | radix | rafael: that's probably not the right way to put it |
| 18:27.31 | radix | rafael: Storm allows you to use Storm behind the scenes with code that was written for SQLObject |
| 18:27.41 | radix | rafael: the point of it is to make it easy to port your legacy SQLObject-using code to Storm. |
| 18:28.00 | radix | rafael: Launchpad used to use SQLobject, but it is switching to Storm. We couldn't rewrite all of it at once, so we wrote the emulation layer. |
| 18:29.44 | rafael | so its something like a sqlobject2storm formatter? |
| 18:29.56 | radix | sure :) |
| 18:30.06 | radix | it doesn't rewrite your code, it just exposes the same API as SQLObject. |
| 18:30.37 | rafael | ? |
| 18:31.25 | jkakar | Oh man. It would be SO awesome if it could rewrite code. |
| 18:31.46 | jkakar | It would have to generate tests and do the red/green refactoring, of course. ;) |
| 18:31.51 | radix | heh |
| 18:38.13 | rafael | radix: what do you mean with "it doesn't rewrite your code, it just exposes the same API as SQLObject." ? |
| 18:38.51 | radix | rafael: Do you know what I mean by "API"? |
| 18:39.05 | rafael | yep |
| 18:39.20 | radix | rafael: ok, so SQLObject has an API. It's made up of a class named "SQLObject" with a bunch of methods and attributes and stuff. |
| 18:39.50 | radix | rafael: you're meant to subclass it in your app to make objects which are bound to rows in the database, etc. |
| 18:40.34 | radix | rafael: Storm provides the *same* API, at a module named "storm.sqlobject", so that if you previously wrote code that uses SQLObject, you can do some minor changes to your code to make it use Storm instead of SQLObject. |
| 18:41.32 | rafael | ah, i understand. nice thing |
| 18:41.37 | radix | This is to allow you to start incrementally using Storm without rewriting all of your code to use native Storm APIs |
| 18:42.05 | radix | Nobody should use the storm.sqlobject module unless they're porting an application which previously used SQLobject. |
| 18:42.12 | rafael | so you can use storm but rewrite it in storm later |
| 18:42.14 | rafael | ? |
| 18:42.32 | radix | right. You can change bits of your app to use the native Storm APIs, one at a time. |
| 18:42.56 | rafael | nice :) but there isn't so much documentation at the moment.. |
| 18:43.07 | radix | no, unfortunately. There is the tutorial and a smattering of docstrings. |
| 18:43.15 | radix | We've recently become more stringent about docstrings, so that should be improving. |
| 18:43.51 | radix | hopefully eventually we'll be posting an API reference to the web site based on the docstrings. |
| 18:47.56 | rafael | with epydoc? |
| 18:48.02 | radix | probably pydoctor. |
| 18:49.19 | rafael | ReST support? |
| 18:50.39 | radix | hm. I think it just supports epytext and plain text right now |
| 18:50.47 | radix | we've been using epytext mostly |
| 18:51.58 | rafael | i think rest is nicer because its more readable if you read the source |
| 18:56.23 | rafael | how can i see what tables exist in a database? i'm executing code from the tutorial but i get "<class 'pysqlite2.dbapi2.OperationalError'>: no such table: employee" |
| 19:05.48 | radix | rafael: storm doesn't give you an API for that; use whatever mechanism you use to see what tables you have for your given database |
| 19:06.03 | radix | in postgres it's \dt |
| 19:06.06 | radix | (at a psql prompt) |
| 19:08.14 | statik | rafael: for sqlite it's sqlite3, which gives you a prompt that you can use to open your DB file |
| 19:08.39 | statik | I think the command is .tables or something |
| 19:09.40 | rafael | but i'm using the memory database |
| 19:14.56 | statik | yeah, sqlite3 can use a memory db too, but I don't know that you can connect to an in memory DB that is running in another process (where you are using storm). Sounds like the easiest thing might be to just put it in a file so you can inspect the DB and figure out what is going on |
| 19:17.29 | radix | you may be able to do something like store.execute(".tables")? |
| 19:20.22 | creiht | radix: So will there be a storm.sqlalchemy compatibility layer? |
| 19:21.19 | radix | creiht: unlikely. SQLAlchemy would be significantly harder to emulate and we don't have any need to do it, since we don't have any software which uses it |
| 19:21.30 | radix | but patches are accepted :) |
| 19:21.30 | creiht | ahh |
| 19:23.12 | rafael | sorry guys, i must get off now. see you tomorrow and thank you very much for your help |
| 19:23.22 | radix | you're welcome. see you later. |
| 19:25.06 | creiht | So if I am a sqlalchemy user then, what would be the compelling reason to switch to storm? |
| 19:25.56 | radix | creiht: Well, we found some terrible bugs in sqlalchemy, and trying to fix them was extremely problematic (the code was very spaghetti-ish) |
| 19:26.24 | creiht | radix: What version was that at? |
| 19:26.26 | radix | creiht: just feature-wise, storm is much less complex conceptually |
| 19:26.37 | radix | creiht: pre-2 and 2+ |
| 19:26.44 | radix | (or do I mean pre-0.2 and 0.2+? I can't remember) |
| 19:27.02 | radix | we specifically waited for the "big rewrite release" but still had big problems after it was released, some of them the same |
| 19:27.11 | creiht | So are the bugs still in .3? |
| 19:27.29 | radix | I don't know. we switched before then. |
| 19:27.37 | niemeyer | radix: Yeah, I think it was 0.1.X and 0.2.X |
| 19:27.41 | radix | Ok |
| 19:27.45 | niemeyer | Oh, hello, btw |
| 19:27.47 | creiht | Are there ticket numbers that I could look it up? |
| 19:28.37 | creiht | To see if the bugs have been addressed? |
| 19:28.38 | radix | not that I have on file any more |
| 19:28.45 | creiht | bummer |
| 19:29.10 | radix | we went through several rounds of bugfixes with sqlalchemy, actually getting patches applied |
| 19:29.46 | creiht | So if I understand SQLA conceptually, what technically does storm have to offer (or will inthe future) that I can't get with SQLA? |
| 19:29.50 | radix | after finding more really bad bugs, we decided it was time to stop. The nastiest I remember (never actually finding the cause) was an SQL re-ordering bug that would randomly cause objects to become corrupt |
| 19:30.19 | radix | creiht: Not counting anything about bugs, the main feature is that Storm's conceptual model is very straight-forward |
| 19:30.39 | radix | creiht: Storm does exactly what's necessary with transactions and object caching |
| 19:30.49 | creiht | So you are saying there is less of a learning curve? |
| 19:30.49 | radix | without adding lots of extra concepts |
| 19:31.02 | radix | creiht: I guess so. It's not just learning curve, it's also long-term maintenance |
| 19:31.22 | radix | creiht: We continuously bashed our head against the strangeness of "Sessions" in SQLAlchemy |
| 19:31.41 | creiht | What types of strangeness? |
| 19:31.42 | radix | creiht: but anyone who understands how SQL databases work really just want simple transaction management, since the database already implements it well for you. |
| 19:31.49 | radix | creiht: Well, the strangeness of their existence :) |
| 19:32.05 | creiht | ok |
| 19:33.24 | creiht | I'm not seeing much of a compelling argument |
| 19:33.37 | radix | creiht: Well, the only reason we implemented Storm was to have something that worked. |
| 19:33.55 | radix | creiht: SQLAlchemy didn't, and it was extremely hard to fix, so Storm was born. |
| 19:34.07 | creiht | radix: Understood |
| 19:34.50 | niemeyer | creiht: I've described some high-level differences here: http://permalink.gmane.org/gmane.comp.python.storm/15 |
| 19:34.50 | radix | Probably people will start using Storm because it's easier to understand while maintaining many of the important high-level ORM features (object caching / identity management, etc) without unnecessary complexit. |
| 19:34.59 | radix | niemeyer: thanks :) |
| 19:35.11 | creiht | I'm just trying to figure out if there is a reason for me to look at storm over what I have been doing in SQLA |
| 19:35.16 | niemeyer | creiht: We could list specific-features as well, such as lazy expressions and whatnot.. |
| 19:35.45 | creiht | radix: And are you aware of Elixir? |
| 19:35.54 | niemeyer | creiht: But to be honest, if you're using SQLAlchemy in a project and are happy with it, there's no reason to change.. |
| 19:36.14 | radix | creiht: nope. |
| 19:36.17 | niemeyer | creiht: and I consider that to be true for any software comparison |
| 19:37.06 | creiht | Elixir is an Active Record type plugin for SQLA... You could consider it conceptually easier :) |
| 19:37.19 | radix | creiht: I'm aware of it now. |
| 19:37.27 | niemeyer | creiht: I consider conceptually an elephant :-) |
| 19:37.31 | radix | creiht: mmh, except that there's still all of SQLALchemy underneath it :) |
| 19:37.49 | radix | so maybe it provides a simpler API, but I'm still really wary of all that code underneath it. |
| 19:37.56 | creiht | I see |
| 19:38.05 | niemeyer | creiht: There's a considerable layer, and then yet another layer to make the API bearable.. |
| 19:38.07 | creiht | The code that you saw over a major revision ago |
| 19:38.13 | creiht | given that .4 is about to be released |
| 19:38.54 | radix | creiht: yeah. |
| 19:39.16 | creiht | Thanks for the input though |
| 19:39.21 | radix | you're welcome. |
| 19:39.49 | niemeyer | creiht: Have you looked at the tutorial? |
| 19:39.57 | creiht | niemeyer: Yes |
| 19:39.58 | radix | I hope you'll try out storm for any other projects that aren't using SQLAlchemy, so we'll have another more modern comparison to make. |
| 19:40.31 | niemeyer | creiht: and you're used to SQLAlchemy, right? |
| 19:40.37 | creiht | niemeyer: Yes |
| 19:40.42 | niemeyer | creiht: So how does it feel? |
| 19:40.49 | creiht | Not in any large projects yet |
| 19:41.05 | creiht | Mostly proof of concepts for work |
| 19:41.11 | niemeyer | I see |
| 19:41.43 | creiht | But mapping large enough and very crazy schemas to be comfortable with it |
| 19:41.44 | niemeyer | creiht: and how do you think it compares, from the high-level overview of SQLAlchemy you've had, and the superficial look at the tutorial? |
| 19:42.28 | creiht | Well the initial "superficial" look leaves me with: |
| 19:43.01 | creiht | 1. I'm not real fond of having to create the tables with SQL |
| 19:44.17 | creiht | 2. (This is more of a personal opinion) Using class attributes for table meta data (I think this comes from our internally written ORM from a long time ago) |
| 19:44.51 | creiht | 3. Setting up your classes doesn't seem to take as much code with Storm |
| 19:45.04 | radix | creiht: #2 left off whether you think it's good or bad :) |
| 19:45.09 | creiht | bad |
| 19:45.10 | creiht | :) |
| 19:45.11 | creiht | sorry |
| 19:45.13 | radix | ok |
| 19:45.18 | creiht | And that is more opinion than anything else |
| 19:45.20 | radix | creiht: by "table metadata", you mean ...? |
| 19:45.25 | radix | __storm_table__ or something? |
| 19:45.26 | creiht | table name |
| 19:45.29 | creiht | yeah |
| 19:45.32 | radix | how would you prefer that to be specified? |
| 19:45.44 | creiht | radix: Well you would not like how I like it :) |
| 19:46.02 | creiht | I actually like how SQLA maps the meta data |
| 19:46.22 | radix | I can't remember how it does. Implicitly based on the class name? |
| 19:47.07 | niemeyer | radix: You define the whole table with all fields, and then say mapper(...) on the class |
| 19:47.17 | niemeyer | radix: and it magically changes your class entirely :-) |
| 19:47.44 | creiht | yeah... what niemeyer said |
| 19:47.45 | radix | oh *right* |
| 19:47.45 | radix | it's all flooding back |
| 19:50.24 | radix | creiht: so yeah, the fact that we do #2 is one of the reasons why #3 is true |
| 19:50.33 | creiht | radix: indeed |
| 19:51.25 | niemeyer | It's also part of the overall design.. we don't hack the class up in any way |
| 19:52.04 | niemeyer | It doesn't even require a base class or metaclass.. |
| 19:52.20 | creiht | niemeyer: Neither does SQLA |
| 19:52.34 | jkakar | It's interesting that a number of people are mentioning SQL-based table creation as a problem. I find the opposite to be true; it's so much simpler than complicated schema-definition systems. |
| 19:52.43 | radix | so yeah, speaking of which |
| 19:52.51 | niemeyer | creiht: Well.. what does mapper() do? |
| 19:53.00 | creiht | Well I meant to the base class part :) |
| 19:53.25 | creiht | jkakar: It is more a matter of preference |
| 19:53.36 | creiht | Which is fine with me |
| 19:54.10 | jkakar | creiht: Agreed. I just didn't expect it to be something people would be unhappy/uncomfortable with. |
| 19:54.39 | niemeyer | creiht: Indeed.. most of it is |
| 19:54.54 | creiht | jkakar: The reason that I don't like having to create the tables as well is that it seems like a lot of duplication fo work |
| 19:55.05 | creiht | I only say this from experience with our current in house ORM |
| 19:55.16 | niemeyer | creiht: So it's an easy choice.. that's a core design decision that won't change really |
| 19:55.28 | creiht | I have do define the class that is going to map to a table, and also create the SQL and hope that both match appropriately |
| 19:55.35 | creiht | hehe |
| 19:55.48 | statik | niemeyer: it's probably worth adding a FAQ item pointing to the first chapter of the _Refactoring Databases_ book so people can learn about why they should use DDL scripts |
| 19:56.40 | creiht | But either way, SQLA doesn't force you to generate your tables if you don't want to :) |
| 19:56.40 | niemeyer | statik: Indeed |
| 19:56.51 | niemeyer | statik: There's an interesting article about it as well, specifically talking about python: http://spyced.blogspot.com/2006/02/why-schema-definition-belongs-in.html |
| 19:57.03 | creiht | The other problem we had is when you work on a large team, not everyone is a SQL expert :) |
| 19:57.08 | niemeyer | creiht: Introspection? |
| 19:57.31 | creiht | niemeyer: Well that wasn't what I was specifically talking about |
| 19:57.33 | niemeyer | creiht: In large teams in the real world, there are DBAs which are responsible for the schema |
| 19:57.46 | niemeyer | creiht: You're not *allowed* to use such a tool, in most organizations |
| 19:58.00 | niemeyer | creiht: But that doesn't make a point here, in any case.. |
| 19:58.05 | creiht | niemeyer: That sounds nice in theory, but sometimes (unfortunately) that is not how it works in the real world |
| 19:58.10 | creiht | at least in my case |
| 19:58.36 | niemeyer | creiht: Really? I'm interested on it from a learning perspective then |
| 19:58.40 | creiht | But again... I wasn't wanting to camp on this |
| 19:58.48 | creiht | It is a rather small thing in the larger picture |
| 19:58.49 | radix | well, I don't see a problem in adding some optional schema generation code to Storm |
| 19:58.59 | niemeyer | creiht: Do you work on a large team which doesn't do schema management and instead use Python wrappers? |
| 19:59.07 | creiht | Currently |
| 19:59.14 | creiht | We have a medium sized team |
| 19:59.22 | creiht | And we have DBAs |
| 19:59.30 | niemeyer | radix: It would require adding database-specific typing |
| 19:59.33 | creiht | But we have too much work for them to design all the schemas |
| 19:59.36 | radix | niemeyer: indeed |
| 19:59.38 | niemeyer | radix: SmallInt() etc |
| 19:59.57 | creiht | So the DBA's review the schemas |
| 20:00.34 | niemeyer | creiht: In Python? |
| 20:00.41 | creiht | no it is all done in SQL |
| 20:00.45 | creiht | at the moment |
| 20:00.50 | niemeyer | creiht: Heh |
| 20:01.19 | radix | creiht: how do you manage upgrades, btw? |
| 20:01.28 | creiht | sigh |
| 20:01.49 | creiht | So we are going way too far down a rabbit hole |
| 20:01.54 | radix | er... for the record, that was honestly not a pointed question |
| 20:02.00 | creiht | oh I know |
| 20:02.21 | creiht | And I'm not trying to say schema generation is always the perfect solution |
| 20:02.23 | radix | I'm thinking about schema generation, and often that kind has certain implications on upgrading |
| 20:02.31 | creiht | indeed |
| 20:02.40 | creiht | You still have to write SQL for upgrages |
| 20:02.45 | radix | depending on what kind of upgrade system you want, anyway |
| 20:02.56 | radix | well, maybe :) |
| 20:03.10 | creiht | anyways... In the grand scheme of things |
| 20:03.12 | radix | Axiom, for example, does not require you to write SQL for upgrades, but has a very high-level upgrade system |
| 20:03.16 | creiht | It's a very little point |
| 20:03.27 | radix | alright, cool |
| 20:03.39 | creiht | It just makes getting started a lot easier |
| 20:03.42 | radix | but I really am curious if you have any suggestions, because you're not the first person to mention schema generation in the context of Storm |
| 20:03.56 | creiht | I think what I just said is the biggie |
| 20:04.03 | creiht | It makes getting started much easier |
| 20:04.15 | creiht | Especially for those who are not quite as SQL savvy |
| 20:04.26 | creiht | And those who want to just write a small blog app |
| 20:05.50 | radix | right. |
| 20:06.03 | creiht | All I know from experience... Is that I dread having to create new tables in our current system because I have to both create a class that maps the table, and the table in SQL and hope that they both match correctly |
| 20:07.52 | jkakar | Won't your tests blow up if the schema/class definition don't match up? |
| 20:07.55 | radix | Yeah. I haven't really found it very dreadful in my app, but I do note the duplication. |
| 20:08.07 | radix | maybe I don't dread it so much because I do TDD :) |
| 20:08.34 | niemeyer | jkakar: Not necessarily |
| 20:08.41 | niemeyer | jkakar: It depends on the conflict |
| 20:08.43 | creiht | Right... and while we don't quite do TDD, the unit tests do find the problems |
| 20:09.03 | creiht | But the pain is going back to try to find where I mispelled one of the columns or something like that |
| 20:09.07 | jkakar | niemeyer: Yeah, I can imagine that. |
| 20:09.09 | niemeyer | jkakar: If you've got e.g. a text field with length 50 and your code says 25, nothing will ever blow up |
| 20:09.26 | jkakar | niemeyer: Right. |
| 20:10.02 | creiht | It's just a lot simpler when you know the tables you generated will match the code you created |
| 20:10.11 | creiht | And it does come with tradeoffs |
| 20:10.20 | creiht | But for some people (like me) that is preferable |
| 20:10.25 | niemeyer | creiht: Hmm |
| 20:10.54 | creiht | anyways |
| 20:10.55 | creiht | :) |
| 20:11.00 | niemeyer | creiht: In projects we use Storm on the code always match the table |
| 20:11.05 | niemeyer | creiht: Because there's no duplication |
| 20:11.53 | creiht | niemeyer: Well for me it eventually does, after I figure out what SQL mistakes I had made in generating the table (or in a lot of the cases, typos) |
| 20:12.17 | creiht | like I said |
| 20:12.28 | creiht | I didn't mean to go so far down the rabbit hole :) |
| 20:12.43 | niemeyer | creiht: Me neither to be honest |
| 20:12.55 | niemeyer | creiht: But it's good to have your feedback, thanks |
| 20:13.52 | creiht | niemeyer: On the other side of things... It would be interesting to hear your opinion on what the SQLA code looks like now that .3 has been out (which was another major revolution in the code) and .4 will be out soon |
| 20:16.53 | creiht | niemeyer: So to more important topics |
| 20:17.24 | creiht | How do you control lazy loading of colums in storm? |
| 20:17.34 | creiht | Say you have forign keys to objects |
| 20:17.42 | creiht | Some you want to load on the initial load of the data |
| 20:17.46 | creiht | and some you don't |
| 20:17.46 | niemeyer | creiht: I appreciate your interest on my review, but I confess that I don't have a lot of time or motivation for it |
| 20:17.54 | creiht | niemeyer: Understood |
| 20:18.29 | niemeyer | creiht: When we reported these issues originally.. no one really paid much attention |
| 20:18.39 | niemeyer | creiht: (at least not when we reported them) |
| 20:18.48 | creiht | niemeyer: I understand your motivations |
| 20:18.56 | creiht | I just don't see that type of things happening todya |
| 20:19.07 | creiht | So you have to understand where I am coming from as well |
| 20:19.18 | niemeyer | creiht: So, about lazy expressions |
| 20:19.21 | creiht | yes |
| 20:19.23 | creiht | :) |
| 20:19.47 | niemeyer | creiht: People said the same thing before we started Storm.. but.. anyway.. :-) |
| 20:20.01 | niemeyer | creiht: Lazy values are subclasses of a specific type |
| 20:20.23 | niemeyer | creiht: Or, the type of a lazy expression is a subclass of a given type |
| 20:20.32 | creiht | niemeyer: I couldn't find reference to that type of thing in the tutorial |
| 20:20.38 | niemeyer | creiht: and these lazy values emit an event when they need resolving |
| 20:20.46 | creiht | ahh ok |
| 20:20.52 | niemeyer | creiht: The tutorial is pretty short on most topics |
| 20:20.58 | creiht | yeah |
| 20:21.11 | niemeyer | creiht: There's a lot to be said about each of these covered entries, and there's a lot missing as well |
| 20:21.28 | niemeyer | creiht: It was just a quick hack to not release it without any kind of documentation |
| 20:21.33 | creiht | So if I define a field as lazy loaded |
| 20:21.37 | creiht | understood |
| 20:22.08 | creiht | Is there a way to override that (say for performance reasons) to have it pull that information in one query |
| 20:22.20 | niemeyer | creiht: Which information? |
| 20:22.30 | niemeyer | creiht: I mean, can you give me a bit more context? |
| 20:22.32 | creiht | Say I have a many to one relationship |
| 20:22.37 | niemeyer | Ok |
| 20:22.45 | creiht | Where an object could reference a whole lot of other objects |
| 20:22.56 | creiht | And say 90% of the time, I don't need that extra information |
| 20:23.14 | creiht | So I set that field as lazy load |
| 20:23.16 | niemeyer | creiht: References don't use lazy evaluation |
| 20:23.24 | niemeyer | creiht: Ah, I see |
| 20:23.46 | niemeyer | creiht: So you want the foreign key *column* (e.g. the remote id), to be lazy loaded as well? |
| 20:24.07 | creiht | hrmm... maybe I'm not explaining it right |
| 20:24.16 | creiht | A more concrete example: |
| 20:24.21 | creiht | (though a bit contrived) |
| 20:24.44 | creiht | hrmm |
| 20:24.49 | creiht | Say I have an address table |
| 20:24.50 | radix | niemeyer: you should probably clarify what you mean by "References don't use lazy evaluation"... |
| 20:25.08 | creiht | radix: good point :) |
| 20:25.27 | niemeyer | I think I'll wait for the example.. I seem to be in another page entirely |
| 20:25.35 | creiht | hehe |
| 20:25.36 | creiht | ok |
| 20:25.46 | radix | References don't use the thing called "Lazy loading" in Storm, but they don't get loaded until you access the attribute explicitly |
| 20:26.09 | radix | certainly, continue |
| 20:26.11 | creiht | That would seem to be lazy loading :) |
| 20:26.33 | niemeyer | creiht: It is.. |
| 20:26.42 | creiht | anyways |
| 20:26.43 | creiht | :) |
| 20:26.47 | niemeyer | creiht: But it's not what we call lazy expressions |
| 20:26.52 | creiht | ok |
| 20:26.58 | radix | sorry that's what I meant to say |
| 20:27.10 | creiht | That makes more sense |
| 20:28.07 | creiht | okay so this is a bit contrived |
| 20:28.15 | creiht | But hopefully you will follow |
| 20:28.38 | creiht | Say you have an address table that store addresses of customers |
| 20:29.00 | creiht | actully that will be too contived :) |
| 20:29.02 | creiht | hrmm |
| 20:29.15 | creiht | ahhh |
| 20:29.16 | creiht | ok |
| 20:29.22 | creiht | So say you are desiging a game |
| 20:29.29 | creiht | and MMORPG |
| 20:29.42 | niemeyer | Wow.. :) |
| 20:29.43 | niemeyer | Ok |
| 20:29.46 | creiht | hehe |
| 20:29.50 | creiht | I wanted to change it up a bit |
| 20:29.53 | creiht | have some fun :) |
| 20:30.02 | creiht | And you have an item table |
| 20:30.18 | creiht | that is basically a table of all the available items |
| 20:30.43 | niemeyer | Ok |
| 20:31.06 | creiht | That table has basically a many to one relationship with the player table |
| 20:31.16 | creiht | well more likely a many to many |
| 20:31.21 | creiht | But this makes it simpler |
| 20:31.23 | creiht | anyways |
| 20:31.42 | creiht | so this "item" class could have a players attribute |
| 20:31.56 | creiht | that would be list of all the player objects that have that item |
| 20:32.14 | creiht | You would want that to be lazy loaded |
| 20:32.30 | creiht | So that if you did a load of the item, by default you wouldn't want to load all of the player objects as well |
| 20:32.40 | creiht | follow me so far? |
| 20:32.44 | niemeyer | Yep! |
| 20:32.52 | niemeyer | That's how it works |
| 20:33.01 | creiht | So say in a certain instance |
| 20:33.08 | creiht | (the 10% case) |
| 20:33.12 | creiht | for performance reasons |
| 20:33.15 | creiht | When you load the item |
| 20:33.28 | creiht | You would like for it to pull all the player objects in as well |
| 20:33.33 | niemeyer | Right |
| 20:33.38 | creiht | So basically running one query instead of two |
| 20:33.43 | niemeyer | We use tuple loading in these cases |
| 20:33.57 | creiht | oh |
| 20:34.11 | creiht | I must have missed that sorry... which section am I looking for? |
| 20:35.02 | niemeyer | Man.. how lame |
| 20:35.07 | niemeyer | You haven't missed it.. I did |
| 20:35.11 | creiht | hehe |
| 20:35.23 | niemeyer | creiht: Wait a moment.. I'll add a section |
| 20:35.28 | creiht | hehe |
| 20:35.29 | creiht | ok |
| 20:43.44 | niemeyer | creiht: Done |
| 20:44.03 | niemeyer | "Many objects with one query" |
| 20:44.28 | creiht | "Internal Server Error" |
| 20:44.44 | creiht | ahh now it loaded |
| 20:45.16 | creiht | ahhh |
| 20:45.17 | creiht | I see |
| 20:46.25 | creiht | hrmm |
| 20:46.28 | radix | probably some leftover slashdotting effects |
| 20:49.17 | creiht | Well thanks for the time... I should get some work done now :) |
| 20:50.05 | niemeyer | creiht: My pleasure |
| 20:50.36 | creiht | I just wish you guys could have gotten along better... :) |
| 20:52.09 | niemeyer | creiht: In which sense? |
| 20:52.35 | creiht | Well whatever happened... It was enough for you to start you project |
| 20:52.56 | creiht | There are always 2 sides to a story |
| 20:53.03 | niemeyer | creiht: Ah, I see.. you mean Storm and SQLAlchemy developers |
| 20:53.06 | creiht | And I'm not trying to get in the middle of it :) |
| 20:53.07 | creiht | yes |
| 20:53.28 | niemeyer | creiht: Well, we tried at least |
| 20:53.31 | creiht | But in the end I hope it is good for both, as competition is always a good thing |
| 20:53.51 | niemeyer | creiht: Then there was a point where had to make a choice, and looking back it was the right choice |
| 20:54.27 | niemeyer | creiht: I said that not just because of Storm being released now, but because we moved on our real objective with less issues |
| 20:54.32 | niemeyer | s/said/say/ |
| 20:54.47 | radix | hah!! |
| 20:54.48 | niemeyer | jbot: Wow.. thanks :-) |
| 20:54.50 | creiht | hehe |
| 20:54.53 | creiht | nice bot :) |
| 20:55.15 | radix | I want my IRC client to do that automatically, with a little colored animation... :) |
| 20:55.35 | creiht | radix: If you wrote your own it wouldn't be difficult :) |
| 20:55.42 | niemeyer | radix: xchat + xchat-python = profit! |
| 20:55.47 | radix | creiht: I'm sick of writing my own software :) |
| 20:55.48 | creiht | s/:)/;) |
| 20:56.05 | creiht | the bot doesn't like me :( |
| 20:56.19 | radix | creiht: maybe it requires a trailing slash |
| 20:56.21 | niemeyer | <PROTECTED> |
| 20:56.21 | niemeyer | <PROTECTED> |
| 20:56.21 | niemeyer | <PROTECTED> |
| 20:56.21 | niemeyer | <PROTECTED> |
| 20:56.21 | niemeyer | <PROTECTED> |
| 20:56.23 | niemeyer | <PROTECTED> |
| 20:56.23 | niemeyer | <PROTECTED> |
| 20:56.27 | niemeyer | That's an xchat-python plugin.. |
| 20:56.29 | radix | ZOMG |
| 20:56.32 | niemeyer | (yes, I was bothered) |
| 20:56.41 | creiht | s/:)/;)/ |
| 20:57.19 | radix | s/ZOMG/zOh My God/ |
| 20:57.27 | radix | creiht: you lost last-line context that time :) |
| 20:57.32 | creiht | yeah I know |
| 20:57.38 | creiht | realized that just after I hit enter |
| 20:58.47 | niemeyer | Ok.. I better do something as well |
| 21:13.58 | *** join/#storm dialtone (i=dialtone@conference/europython/x-e34f9d883e0245ae) |
| 22:27.40 | niemeyer | Good night everyone |
| 22:28.19 | tjs | morning |
| 22:29.10 | niemeyer | tjs: Morning! :-) |
| 22:29.16 | niemeyer | See you in a bit :-) |
| 22:29.20 | tjs | :) |
| 22:29.24 | tjs | sleep well |
| 22:29.35 | niemeyer | Thanks! |
| 22:34.04 | tjs | radix: any word on that glue stuff? I'm just starting hacking up an IInitIds implementation that will bridge the gap between ZODB objects with UIDs and storm objects (which will in our app also have UIDs) |
| 22:34.44 | tjs | but I can't really start using it in our app without thread local store access |
| 22:34.58 | tjs | I'm avoiding writing that myself atm, no point reinventing the wheel |
| 22:43.08 | radix | tjs: don't forget the transaction-glue, which is also part of zstorm |
| 22:43.11 | radix | tjs: but no, no word on it yet |
| 22:44.05 | radix | tjs: we have sent the request to the Boss Man, though |
| 22:46.17 | tjs | zstorm |
| 22:46.20 | tjs | I love it |
| 22:46.41 | tjs | sounds very uber-xmen |
| 22:48.24 | tjs | radix: lots of marvel comic related jokes in this project? |
| 22:48.36 | radix | none intentionally :P |
| 22:49.38 | tjs | :) |
| 22:56.19 | *** join/#storm brosner (n=brian@63.150.173.39) |
| 23:05.48 | brosner | i am creating a model called Account which has been referenced by the model Transaction. i am wondering if i can create a method in the Account method to get the balance of the account then map it a property using property(). i just found out about storm and am playing with it. i didn't see an information on the storm site. not sure if this possible or just how to go about it. seems like i would need a store object passed into the balance method somehow. |
| 23:09.32 | tjs | brosner: that was not really clear |
| 23:09.38 | jkakar | brosner: Is the relationship between Account and Transaction 1-to-1? |
| 23:10.02 | brosner | an account has many transactions |
| 23:10.04 | jkakar | brosner: You can use a Reference to make, for example, Account.transaction be a "property" that yields the referenced Transaction. |
| 23:10.16 | jkakar | brosner: Ah, in that case you want a ReferenceSet. |
| 23:10.46 | brosner | jkakar: ah and define that in the Account model |
| 23:10.56 | jkakar | brosner: Yep. |
| 23:11.25 | brosner | jkakar: perfect then i can call that to iterate over the transactions belonging to that account? |
| 23:11.44 | jkakar | brosner: Exactly. |
| 23:12.30 | brosner | great, and the use of property() in a model won't mess up anything since there isn't much introspection on models right? |
| 23:12.39 | tjs | if you just want a sum of values from all transactions related to an account, couldnt you use an expression value (see tutorial) and not wake all those objects? |
| 23:13.19 | jkakar | brosner: Right. |
| 23:13.33 | jkakar | tjs: Yeah, that's an even better way to do it. |
| 23:13.34 | jkakar | In fact. |
| 23:13.53 | brosner | tjs: haven't looked into that yet, but i know i have two subclasses of a Transaction: Expense and Deposit |
| 23:14.01 | tjs | considering (by the sounds of it) there could be a large number of transactions |
| 23:14.08 | brosner | not sure if that would effect this expression value which i have not looked into |
| 23:14.11 | tjs | that would also give you the property() like api you want |
| 23:14.28 | brosner | all i want with the property() is to do account.balance |
| 23:14.29 | tjs | I doubt you want to implement set anyway, as it makes little sense |
| 23:14.35 | brosner | right |
| 23:14.46 | tjs | yeh so look at the storm tute |
| 23:14.50 | tjs | at Expression Values |
| 23:15.05 | tjs | in your class you would go: |
| 23:15.23 | jkakar | Sure, you might want to run a general query instead of doing the iteration. |
| 23:15.44 | tjs | balance = SQL("SELECT SUM(.. |
| 23:16.01 | tjs | its been a while since I've done sql ;) |
| 23:17.08 | jkakar | You likely want to use the Sum expression, not raw SQL. |
| 23:17.21 | tjs | aye |
| 23:17.59 | brosner | yeah i will have to look at the object since i have the Expense and Deposit subclasses to determine how it affects the balance |
| 23:18.02 | jkakar | something like 'result = store.execute(Select(Sum(Transaction.balance), Transaction.account_id == Account.id)' |
| 23:18.13 | tjs | jkakar: you can use the python sql expression syntax and assign that to an attribute? |
| 23:18.14 | jkakar | brosner: That could be trickier. :) |
| 23:18.59 | jkakar | tjs: I'm not sure I entirely understand the question. store.execute() returns a ResultSet. |
| 23:19.08 | jkakar | tjs: You could do this too: |
| 23:19.18 | jkakar | query = Select(...) |
| 23:19.23 | jkakar | result = store.execute(query) |
| 23:19.28 | brosner | well i need to run all thanks for your jump start. i will be back around though. btw is this logged anywhere on the internet? |
| 23:19.29 | jkakar | Is that what you're asking about? |
| 23:19.34 | jkakar | brosner: Cool! |
| 23:20.05 | tjs | aah! |
| 23:20.23 | jkakar | :) |
| 23:20.25 | tjs | I think I misunderstand the expression values section |
| 23:20.34 | jkakar | Any suggestions for improving the tutorial? |
| 23:21.02 | tjs | well, I guess I was looking for more black magic rather than the obvious |
| 23:21.06 | jkakar | Hehehe |
| 23:21.15 | tjs | but the Expression values section to me said: |
| 23:21.27 | jkakar | tjs: In practice, we've used store.execute() very rarely, and rarely had to use the expression building possibilities of Storm. |
| 23:21.47 | jkakar | tjs: Most of the time we do Store.find(SomeObj, SomeObj's where clause). |
| 23:21.47 | tjs | assigning SQL() statements to an attribute, meant whenever you accessed that attribute, it would run the sql and return the value |
| 23:22.22 | tjs | yeh |
| 23:22.32 | jkakar | tjs: Ah, I see. I'm not actually sure how that behaves; whether it evaluates the value once (ie: runs the query once) or many times. |
| 23:22.54 | jkakar | tjs: I'd be surprised if it was the later; I suspect it just gets the value and assigns it. |
| 23:23.25 | tjs | its the difference between: ruy.name = SQL("") or ruy.name = property(lambda: SQL("")) |
| 23:23.33 | tjs | yeh |
| 23:23.36 | jkakar | Right. |
| 23:25.18 | tjs | the fact that its assigning it to a member is confusing, I thought there was something special being shown, perhaps the example could just be: |
| 23:25.30 | tjs | >>> SQL("SELECT..") |
| 23:25.40 | tjs | u"Ruy Ritcher" |
| 23:25.53 | jkakar | tjs: Yeah, that might be easier. |
| 23:29.33 | jkakar | tjs: I've just captured our conversation and mailed to niemeyer; I don't understand the expression system well enough to meaningfully update the tutorial but hopefully our conversation will give some hints to niemeyer. |
| 23:40.41 | tjs | sure |
| 23:43.43 | *** join/#storm pbugni (n=pbugni@c-67-171-37-114.hsd1.wa.comcast.net) |
| 23:45.01 | *** part/#storm pbugni (n=pbugni@c-67-171-37-114.hsd1.wa.comcast.net) |
| 23:46.35 | *** join/#storm b52laptop (n=b52lapto@41.249.250.195) |
| 23:51.56 | tjs | radix: it mentions in a few places that one of the intentions of storm was using multiple databases? |
| 23:52.12 | tjs | radix: does the reference mechanism support cross-store references? |
| 23:55.15 | *** part/#storm b52laptop (n=b52lapto@41.249.250.195) |
| 23:56.47 | radix | tjs: no, it doesn't |
| 23:59.00 | tjs | ok |