| 03:37.34 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 04:39.29 | midgetspy | can Storm-inherited classes not have any attributes that aren't backed by the DB? |
| 07:28.04 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 07:52.44 | *** join/#storm danilos (~danilo@canonical/launchpad/danilos) |
| 07:53.36 | *** join/#storm bigjools (~quassel@82-71-93-254.dsl.in-addr.zen.co.uk) |
| 07:53.37 | *** join/#storm bigjools (~quassel@canonical/launchpad/bigjools) |
| 08:02.24 | jkakar | midgetspy: They can, yes, but they can't be Storm properties. |
| 08:10.26 | *** join/#storm keppla (~keppla@i577B119F.versanet.de) |
| 08:16.08 | *** join/#storm elmom_ (~elmom@vallila-gw.hupnet.helsinki.fi) |
| 08:17.11 | *** join/#storm keppla1 (~keppla@i577B1718.versanet.de) |
| 08:22.44 | *** join/#storm keppla (~keppla@i577B1991.versanet.de) |
| 08:25.31 | *** join/#storm keppla1 (~keppla@i577B1CCF.versanet.de) |
| 08:46.12 | *** join/#storm keppla (~keppla@i577B2D63.versanet.de) |
| 08:58.10 | *** join/#storm keppla1 (~keppla@i577B37F3.versanet.de) |
| 09:04.08 | *** join/#storm keppla (~keppla@i577B3D6B.versanet.de) |
| 09:04.39 | *** join/#storm danilos (~danilo@canonical/launchpad/danilos) |
| 09:11.39 | *** join/#storm keppla (~keppla@i577B011D.versanet.de) |
| 09:40.32 | *** join/#storm jukart (lovely@81.189.156.94) |
| 12:31.32 | *** join/#storm infobot (ibot@rikers.org) |
| 12:31.32 | *** topic/#storm is The Storm Python ORM - http://storm.canonical.com/ - 0.16 released! || Review branches: https://code.launchpad.net/storm/+activereviews || IRC logs: http://ibot.rikers.org/#storm/ || API documentation: http://people.canonical.com/~jkakar/storm/ |
| 12:31.56 | *** part/#storm kunal (~kunal@115.99.41.26) |
| 12:32.34 | therve | apparently not :) |
| 12:37.50 | jkakar | :) |
| 15:38.27 | *** join/#storm stub1 (~stub@ppp-58-8-1-38.revip2.asianet.co.th) |
| 15:38.30 | *** join/#storm stub (~stub@canonical/launchpad/stub) |
| 16:54.48 | *** join/#storm jukart (~jukart@d86-32-163-62.cust.tele2.at) |
| 17:46.21 | *** join/#storm elmom_ (~elmom@hoasnet-fe29dd00-137.dhcp.inet.fi) |
| 19:00.30 | midgetspy | does storm ever do an implicit rollback on its own? |
| 19:01.24 | midgetspy | I'm having a multi-threading issue where I'm adding many rows and in some situations when I do something else at the same time some of the data ends up being incomplete |
| 19:02.23 | midgetspy | for example, I create an object, then add another object as a Reference, then commit and if some other DB access happens during that sometimes I end up with the Reference not ending up in the DB (though my logs clearly indicate it happened) |
| 19:03.17 | midgetspy | I haven't tried getting storm to output the SQL debug logs cause it's hard to reproduce and will be hell to sift through |
| 19:03.21 | jkakar | midgetspy: Sounds odd. I think the only time Storm does a rollback is if the connection gets disconnected... but in such a case, you should see DisconnectionError exceptions. |
| 19:03.35 | midgetspy | hm |
| 19:05.16 | midgetspy | I've already made all my accesses use a single store object in a single thread, but apparently that's not enough to stop unrelated accesses from interfering with each other somehow |
| 19:05.44 | midgetspy | the weirder thing is the secondary accesses that are occuring while I add my data (that cause the added data to be incomplete) are just finds |
| 19:34.19 | midgetspy | well I made a bit of progress in reproducing it: http://paste.pocoo.org/show/206444/ |
| 19:39.27 | midgetspy | i wonder what it'd do to performance to force a commit after every single operation |
| 19:42.38 | jkakar | midgetspy: Bad things, both from a performance POV (and likely from a transaction coherence POV) will happen if you commit after every operation. |
| 19:42.47 | jkakar | midgetspy: In your paste Bar has no primary key... is that the case in your application code? |
| 19:44.05 | midgetspy | no, it has one in the app |
| 19:44.19 | midgetspy | I'm sorting through a debug sql dump atm, see if i can make sense of it |
| 19:46.11 | jkakar | midgetspy: Hmm. |
| 19:46.56 | jkakar | midgetspy: It sounds a bit odd. You could try setting Foo.id = Int(primary=True, default=AutoReload). |
| 19:47.10 | jkakar | midgetspy: This will cause the ID to be automatically loaded from the database on first access. from storm.locals import AutoReload. |
| 20:01.09 | midgetspy | it didn't like that |
| 20:01.15 | midgetspy | KeyError: 'primary_vars' |
| 20:01.35 | midgetspy | I'm not sure if that only happened when this bug happened, sifting through logs |
| 20:06.20 | midgetspy | yeah looks like it |
| 20:06.51 | midgetspy | default=AutoReload makes it die with the KeyError exception the first time I trigger that problem |
| 20:21.20 | *** join/#storm fcorrea (~fcorrea@187.3.15.40) |
| 20:23.32 | midgetspy | http://paste.pocoo.org/show/206465/ vs http://paste.pocoo.org/show/206466/ |
| 20:23.54 | midgetspy | the exact same two operations, the first one succeeded, the second fails |
| 20:24.13 | midgetspy | (load them up in two windows side by side) |
| 20:25.28 | midgetspy | you can clearly see line 12 in the first one setting _eid with an UPDATE and there's no such command being executed on the second one |
| 20:26.57 | midgetspy | but I'm kinda out of ideas about how to fix it - the only thing I can think is to lock all store access so that all these commands get executed without interruption... |