| 00:16.01 | *** join/#storm Key_Gena104 (i=lok@gateway/tor/x-ee106e4a4c4c3d51) |
| 01:31.44 | *** join/#storm jml (n=jml@dsl-210-15-197-192-static.TAS.netspace.net.au) |
| 01:42.08 | *** join/#storm michelp (n=michelp@69-30-72-119.dq1sf.easystreet.com) |
| 01:43.18 | niemeyer | radix: ping? |
| 01:44.26 | niemeyer | radix: Hmm.. |
| 01:44.30 | niemeyer | radix: No, it looks like a bug |
| 01:44.46 | niemeyer | radix: There's another bug as well.. |
| 01:44.55 | radix | niemeyer: yo |
| 01:44.58 | radix | niemeyer: ah |
| 01:45.02 | niemeyer | radix: _started should be set before the 'try' in raw_execute |
| 01:45.04 | niemeyer | radix: Heya! |
| 01:45.11 | niemeyer | radix: Explaining: |
| 01:45.44 | niemeyer | radix: The "manual" timeout code should only do something in pysqlite's which have a bug preventing the internal timeout from sqlite to work |
| 01:45.45 | radix | is it about how the patch got rid of the started argument? |
| 01:45.51 | niemeyer | radix: In newer versions, sqlite itself will do the timeout |
| 01:45.52 | radix | ah |
| 01:45.57 | niemeyer | radix: So we don't want to duplicate the timeout |
| 01:46.16 | niemeyer | radix: If we set _started beforehand, only a single timeout will be applied (either the internal one, or the manual one) |
| 01:47.09 | niemeyer | radix: Yeah, we probably don't need the parameter in that new implementation |
| 01:47.16 | niemeyer | radix: Which is probably a silly early optimization anyway |
| 01:47.45 | niemeyer | radix: Does the provided branch provide tests, or we'll have to come up with our own? |
| 01:49.29 | radix | it has a test, but the test it provides is a bit too big |
| 01:49.37 | radix | it should be split up into at least two |
| 02:31.46 | niemeyer | Bed time here.. |
| 02:31.49 | niemeyer | Have a good time everyone |
| 02:34.00 | *** join/#storm Key_Gena104 (i=lok@gateway/tor/x-49a94cced0b1a415) |
| 02:54.18 | *** join/#storm shredwheet (n=pete@cpe-76-169-241-17.socal.res.rr.com) |
| 03:51.41 | *** join/#storm jml (n=jml@ppp121-44-213-76.lns1.hba1.internode.on.net) |
| 03:58.02 | *** join/#storm michelp (n=michelp@69-30-72-119.dq1sf.easystreet.com) |
| 04:55.21 | *** join/#storm jukart (n=jukart@85-124-221-45.static.xdsl-line.inode.at) |
| 06:05.14 | *** join/#storm jukart (n=jukart@lsfw01.lovelysystems.com) |
| 06:18.44 | *** join/#storm dobee (n=dobeee@194.183.146.186) |
| 06:24.50 | *** join/#storm Fujitsu (n=fujitsu@ubuntu/member/fujitsu) |
| 07:09.32 | *** join/#storm mcella (n=michele@ip-176-22.sn2.eutelia.it) |
| 09:44.00 | *** join/#storm jukart (n=jukart@lsfw01.lovelysystems.com) |
| 12:02.02 | *** part/#storm tarjei (n=tarjeih@mail2.bergfald.no) |
| 12:14.14 | *** join/#storm niemeyer (n=niemeyer@200-103-134-216.ctame705.dsl.brasiltelecom.net.br) |
| 12:20.59 | *** join/#storm dobee (n=dobeee@81-223-53-162.dornbirn.xdsl-line.inode.at) |
| 12:25.55 | *** join/#storm dobee (n=dobeee@81-223-53-162.dornbirn.xdsl-line.inode.at) |
| 13:27.21 | *** join/#storm EnTeQuAk (n=EnTeQuAk@p57B9C664.dip0.t-ipconnect.de) |
| 13:45.03 | radix | niemeyer: I figured out what you meant by "_started needs to be set earlier" as I was in bed last night |
| 13:45.22 | niemeyer | radix: Hehehe :-) |
| 13:45.28 | niemeyer | radix: See? Our life is ruined.. :-) |
| 13:45.32 | radix | heh heh |
| 13:46.13 | radix | niemeyer: so in other words, the way that you "allow" either sqlite3 to do the timeout, or do it ourselves, is by only waiting further if the sqlite3 call itself didn't take a long time |
| 13:46.41 | niemeyer | radix: Precisely |
| 13:47.02 | radix | niemeyer: so, this branch does set started at the very beginning |
| 13:47.04 | niemeyer | radix: If it errored out before the supposedly being used timeout has passed |
| 13:48.22 | radix | niemeyer: so it seems fine, afaict. he refactored the timeout code into a _retry_until_timeout method |
| 13:48.31 | radix | and I don't see anything wrong with it |
| 13:49.09 | niemeyer | radix: Is this the sqlite-locked-recovery branch? |
| 13:49.28 | niemeyer | radix: I was concerned about something else, but maybe I just misunderstood it |
| 13:50.02 | radix | yep |
| 13:50.04 | richardb | hi |
| 13:50.07 | radix | hi richardb |
| 13:50.47 | richardb | I see you're discussing my branch. ;-) |
| 13:50.51 | radix | yep |
| 13:51.26 | richardb | Looks like you've just figured out what I was doing with it. Any thing you're still wondering about? |
| 13:51.26 | radix | so, I'll post some review comments |
| 13:51.33 | richardb | Sure |
| 13:52.02 | radix | richardb: we knew what it was about; niemeyer had some concerns which we weren't sure were real |
| 13:53.32 | niemeyer | Nope, they're not real |
| 13:54.09 | niemeyer | Btw, commit() should just be using self.raw_execute |
| 13:54.30 | niemeyer | and as we discussed I don't think the RetryableOperationalError is adequate |
| 13:55.04 | radix | niemeyer: I assume it's not using commit() to avoid the BEGIN |
| 13:55.48 | radix | errr |
| 13:55.54 | radix | I assume commit() is not using raw_execute to avoid the BEGIN |
| 13:56.15 | niemeyer | radix: _in_transaction = False should be moved to after the COMMIT |
| 13:56.23 | radix | ah |
| 13:56.26 | niemeyer | radix: This way BEGIN won't be called |
| 13:56.39 | niemeyer | radix: IIRC, there's another bug open about this as well |
| 13:56.44 | radix | well, I'll let you comment to that effect :) |
| 13:57.19 | niemeyer | radix: Something about how when commit() fails, calling it again won't work because _in_transaction is False |
| 13:59.32 | niemeyer | radix: https://bugs.edge.launchpad.net/storm/+bug/136771 |
| 13:59.33 | ubot3 | Malone bug 136771 in storm "If SQLite commit() fails, transaction status gets incorrectly cleared" [Undecided,New] |
| 13:59.38 | radix | Ok, I made some comments |
| 13:59.42 | niemeyer | It's from richardb as well |
| 13:59.54 | radix | niemeyer: umm, that's the same ticket |
| 14:00.29 | niemeyer | Huh.. that's weird :) |
| 14:00.44 | niemeyer | Perhaps the branch doesn't address that? |
| 14:00.58 | richardb | The branch should address that, IIRC. |
| 14:00.59 | niemeyer | richardb: Does your branch address the problem in the bug description? |
| 14:01.07 | niemeyer | http://codebrowse.launchpad.net/~richardboulton/storm/sqlite-locked-recovery/annotate/richard%40lemurconsulting.com-20070903162549-v92650pbflgkqhq2?file_id=sqlite.py-20060515133106-5e72517844a07e8e |
| 14:01.19 | niemeyer | As far as I can see, the _in_transaction flag is still being cleared before the commit |
| 14:01.56 | radix | it sets it back in the exception handler |
| 14:03.14 | richardb | Yes - you're only still in a transaction if the commit fails with "database is locked", if I understand correctly. |
| 14:03.52 | richardb | The first fix I attempted was simply to move _in_transaction = False to after the call to COMMIT. |
| 14:04.21 | radix | argh |
| 14:04.21 | richardb | But, that leaves our code thinking that a transaction is in progress if the commit fails for some other reason. |
| 14:04.41 | richardb | Whereas sqlite then thinks the transaction has failed. |
| 14:05.22 | niemeyer | richardb: Were you able to reproduce it somehow? |
| 14:05.37 | niemeyer | richardb: I mean.. produce a case where the commit fails and sqlite3 thinks that another transaction has started? |
| 14:05.48 | richardb | Ah. Maybe not. |
| 14:05.59 | richardb | I should write a test case for that situation, and see what actually happens. |
| 14:06.04 | richardb | Rather than just going on the documentation. |
| 14:06.29 | niemeyer | richardb: Well.. if the documentation says that's how it works, I'd trust it as well |
| 14:06.54 | niemeyer | richardb: Do you remember where in the documentation this subject is addressed? |
| 14:07.23 | richardb | Not clearly - I'll try and look it up. |
| 14:07.32 | niemeyer | richardb: Sorry for bothering you about this.. I'd just like to understand better how it's supposed to work |
| 14:07.51 | richardb | No problem. It's made fuzzier by pysqlite2's reinterpretation of the error codes. |
| 14:08.06 | niemeyer | I can see that |
| 14:09.44 | radix | yeah, I just filed a bug about its crappy errors. |
| 14:10.01 | radix | actually, reopened an old one that the pysqlite guy closed with some ill-reasoned comment. |
| 14:10.57 | niemeyer | """ |
| 14:10.58 | niemeyer | If the SQL COMMIT command turns autocommit on and the autocommit logic then tries to commit change but fails because some other process is holding a SHARED lock, then autocommit is turned back off automatically. This allows the user to retry the COMMIT at a later time after the SHARED lock has had an opportunity to clear. |
| 14:10.59 | niemeyer | "" |
| 14:11.44 | niemeyer | I suggest we just assume that a failed commit keeps the transaction open |
| 14:12.00 | richardb | Hmm. Perhaps. |
| 14:12.30 | richardb | I was sure it didn't in the case when it wasn't a failure due to a lock. But I can't remember why I was sure. |
| 14:12.37 | richardb | I'll keep looking a little bit moer. |
| 14:13.02 | niemeyer | richardb: Hmm.. doesn't the text above say otherwise? |
| 14:13.38 | richardb | Um - it says that if commit fails, we're still in the transaction. |
| 14:13.57 | richardb | but only if it fails "because some other process is holding a SHARED lock" |
| 14:14.34 | niemeyer | richardb: Oh, I'm sorry.. I've read your comment reversed |
| 14:14.47 | niemeyer | Yeah |
| 14:14.52 | niemeyer | I wonder how we can reproduce a commit failure |
| 14:15.00 | radix | yeah, what other kind of commit failures are there? |
| 14:16.23 | richardb | Well, thinks like IO errors. (eg, fsync or write reporting an error) |
| 14:18.38 | richardb | Or, if a commit hook callback is installed and returns non 0. (But I don't think that can happen with storm, since we don't use such things) |
| 14:20.01 | richardb | But, looking at the code in sqlite (vdbeaux.c, vedbCommit()), I think that any commit failure will leave a ROLLBACK being needed. |
| 14:20.19 | richardb | I thought it automatically called rollback |
| 14:20.43 | richardb | for some reason. But I think not. |
| 14:22.25 | niemeyer | richardb: Ahh, thanks for checking that out! |
| 14:24.38 | richardb | So, the simple "move self._in_transaction = False to after COMMIT" solution seems right. |
| 14:24.43 | richardb | I'll update the branch accordingly. |
| 14:29.54 | niemeyer | richardb: Thank you! |
| 14:35.42 | *** join/#storm brosner (n=brian@63.150.173.39) |
| 14:35.46 | richardb | Ahhhh. I was wrong. |
| 14:35.58 | richardb | vdbeCommit() is only called by sqlite3VdbeHalt() |
| 14:36.36 | richardb | And, where it is called, sqlite3RollbackAll() is called if the return code is not one of SQLITE_BUSY or SQLITE_OK |
| 14:38.23 | richardb | And, if ROLLBACK is called when a transaction isn't active, SQLite returns an error. |
| 14:38.49 | richardb | So, I'm now going to assert that my current fix in the sqlite-locked-recovery branch is correct. |
| 14:40.27 | *** join/#storm leifkb (n=leifkb@dsl82.brbovtma.sover.net) |
| 14:50.28 | niemeyer | richardb: So I suggest that instead of doing that in commit, we change the _retry_until_timeout function to assert that _in_transaction is True when we're leaving the method in a "database is locked" situation |
| 14:50.35 | niemeyer | This way we don't have to special-case commit |
| 14:52.41 | richardb | Ah. Nice. |
| 14:53.30 | richardb | At least we only have to parse the string in the error object in one place, then... |
| 14:56.10 | richardb | Okay - so here's a question: |
| 14:56.23 | richardb | if we have a SELECT statement which fails for some reason. |
| 14:56.49 | richardb | we will no longer be in a transaction. |
| 14:56.52 | richardb | I think. |
| 15:01.30 | richardb | Ah, no, that kind of failure doesn't cause a rollback. |
| 15:49.04 | richardb | Hmm - having some difficulty breaking this test case up much... |
| 15:49.41 | richardb | Basically, because there's a lot of setup needed to get to the meat of the issue. |
| 15:53.27 | *** join/#storm hagna (n=hagna@70.98.162.62) |
| 16:05.18 | hagna | to get mutual references should I setattr on the classes after they are defined? |
| 16:10.02 | radix | hagna: that works |
| 16:10.25 | richardb | Hmm - I can't push to bazaar.launchpad.net. "ssh: connect to host bazaar.launchpad.net port 22: Connection refused" |
| 16:10.52 | radix | hmm, is it still down? |
| 16:10.58 | radix | there was a similar but different problem yesterday |
| 16:11.21 | richardb | Other than that, I think I've resolved the issues for #136771, though I've only split the testcase in two. |
| 16:11.24 | radix | yeah, and kiko just mentioned the problem in #launchpad |
| 16:11.34 | radix | richardb: that's better :) |
| 16:11.47 | richardb | Indeed. :) |
| 16:12.03 | richardb | I separated out the test for commit() failing to observe the timeout. |
| 16:12.34 | radix | ok, lunch time here |
| 16:17.24 | hagna | a table has primary keys on both of its rows |
| 16:17.39 | hagna | is it ok to primary=True twice in the storm object? |
| 16:33.49 | hagna | since the db is faster than python |
| 16:34.26 | hagna | it's probably better to query again than to alter the data from a previous query |
| 16:34.37 | hagna | than to alter the data from a previous query using python |
| 16:36.29 | niemeyer | hagna: No, because ordering matters |
| 16:36.45 | hagna | niemeyer: ordering? |
| 16:36.52 | niemeyer | hagna: You can define __storm_primary__ = "attr_name_1", "attr_name_2" |
| 16:37.17 | niemeyer | hagna: "db is faster than python" is highly dependent on context, and thus false in many cases |
| 16:38.05 | hagna | niemeyer: interesting |
| 16:38.22 | hagna | so for the schema here http://pastebin.com/m3b648740 |
| 16:38.54 | hagna | the whole tuple isn't the key |
| 16:39.10 | hagna | so I should do __storm_primary__ = "attr_name_1", "attr_name_2" |
| 16:39.30 | niemeyer | hagna: the whole tuple isn't the key? Which tuple? |
| 16:39.40 | hagna | bug_id, group_id |
| 16:39.53 | niemeyer | hagna: Do you mean that it *is* the key? |
| 16:40.05 | hagna | I mean that together it is not the key |
| 16:40.08 | hagna | but each is a key |
| 16:40.12 | hagna | or is that the same thing? |
| 16:40.26 | niemeyer | hagna: Hmm.. I think that there might be some misunderstanding here |
| 16:40.51 | niemeyer | hagna: If both of them are primary keys in a single table, it means that the primary key is *both* of them, not each one individually |
| 16:41.05 | hagna | oh |
| 16:41.22 | niemeyer | hagna: Which makes sense for the kind of table there.. |
| 16:41.31 | hagna | so you couldn't have |
| 16:41.32 | hagna | 1,3 |
| 16:41.33 | hagna | 1,4 |
| 16:41.34 | niemeyer | hagna: It's a v-table/link-table/many-to-many table/you name it |
| 16:41.53 | niemeyer | hagna: Yes, you could |
| 16:41.59 | niemeyer | hagna: Because the key is formed by both |
| 16:42.20 | niemeyer | hagna: If each one of them was a key individually, you couldn't have that |
| 16:42.47 | niemeyer | Such "individual keys" are named indexes, btw |
| 16:43.01 | niemeyer | The term "table key" is usually associated with the primary key |
| 16:43.10 | niemeyer | Which only exist once for a given table |
| 16:43.13 | niemeyer | s/exist/exists |
| 16:43.32 | hagna | niemeyer: and you know they aren't individual keys because why? |
| 16:43.38 | hagna | the schema? |
| 16:43.55 | niemeyer | hagna: Because "individual keys in a table" doesn't exist |
| 16:44.29 | niemeyer | hagna: If you have two columns which are flagged as primary keys, they form a composed key |
| 16:44.47 | hagna | oh ok I get it now |
| 16:45.28 | hagna | and to say it's a composed key I do __storm_primary__ = "attr_name_1", "attr_name_2" |
| 16:45.33 | niemeyer | Bingo |
| 16:45.38 | hagna | yay |
| 16:45.53 | niemeyer | ;) |
| 16:53.27 | hagna | can an object have default values after store.find if those values were not in the db? |
| 16:55.11 | *** join/#storm dobee (n=dobeee@81-223-53-162.dornbirn.xdsl-line.inode.at) |
| 17:01.04 | *** join/#storm EnTeQuAk (n=EnTeQuAk@p57B9ABDE.dip0.t-ipconnect.de) |
| 17:03.58 | hagna | dang these queries aren't right with (Bug.bug_status == u'NEW' or Bug.bug_status == u'ASSIGNED' ) |
| 17:04.04 | hagna | what's the debug statement again |
| 17:04.15 | hagna | so I can see the queries |
| 17:11.35 | richardb | Okay, bazaar.launchpad.net is working again - I've pushed my changes to sqlite-locked-recovery. |
| 17:11.36 | niemeyer | hagna: storm.database.DEBUG = True |
| 17:11.43 | hagna | niemeyer: thanks again |
| 17:11.43 | niemeyer | richardb: Thanks! |
| 17:11.51 | hagna | niemeyer: found it Or and And so nm on that |
| 17:12.09 | niemeyer | hagna: Oh, yeah |
| 17:12.19 | hagna | Bug.bug_status == u'NEW' Or Bug.bug_status == u'ASSIGNED' doesn't like that |
| 17:12.24 | niemeyer | Nope |
| 17:12.49 | niemeyer | You can do Or(a == b, c == d) |
| 17:12.54 | hagna | ahhh |
| 17:12.59 | niemeyer | Or you can do (a == b) | (c == d) |
| 17:13.10 | niemeyer | hagna: Python doesn't allow overloading of 'or' |
| 17:13.11 | hagna | intuitive |
| 17:13.27 | richardb | (Or at least, I think I have. The changes aren't showing up on https://code.edge.launchpad.net/~richardboulton/storm/sqlite-locked-recovery yet, but I expect that's just lagging. Still finding my feet with bzr, though, so let me know if I've messed up.) |
| 17:13.38 | niemeyer | richardb: Takes a bit to get there |
| 17:13.46 | niemeyer | richardb: It's mirrored |
| 17:16.02 | niemeyer | hagna: Hmm |
| 17:16.51 | niemeyer | hagna: Btw, in that specific case, you can use this: Bug.bug_status.is_in(u'ASSIGNED', u'NEW') |
| 17:17.02 | hagna | niemeyer: oh you can |
| 17:17.06 | hagna | cool |
| 17:18.49 | hagna | is_in takes 2 arguments? |
| 17:19.14 | niemeyer | hagna: Hmm, not really.. my bad |
| 17:19.19 | niemeyer | hagna: Should be a sequence |
| 17:19.29 | hagna | oh |
| 17:19.29 | niemeyer | hagna: You can use a tuple or a list |
| 17:19.35 | hagna | right |
| 17:19.49 | hagna | this is starting to look like scheme |
| 17:19.52 | hagna | :) |
| 17:20.09 | niemeyer | Hmmm.. :-) |
| 17:38.29 | radix | of course :-) |
| 18:32.42 | hagna | can you refine queries on a resultset AllUsers(name =='foo') |
| 18:32.49 | *** join/#storm Key_Gena104 (i=lok@gateway/tor/x-eeab48c5a0d35d85) |
| 18:35.54 | hagna | maybe just a list comprehension [k for k in self.report.allOpen if k.reporter_ref.login_name == name] |
| 18:36.04 | hagna | seems slow though |
| 18:39.59 | niemeyer | hagna: That's fetching all objects from the database.. definitely not good |
| 18:40.30 | niemeyer | hagna: Doing the query in the database side is better |
| 18:40.55 | hagna | niemeyer: not all objects in the db just the objects in allOpen |
| 18:40.57 | hagna | right? |
| 18:41.35 | radix | yes |
| 18:41.44 | radix | but do it in the database |
| 18:42.03 | radix | I don't know what "on a resultset AllUsers(name =='foo')" means, though, so I can't easy tell you how to refine it |
| 18:53.36 | hagna | how do I select all the users in the profile table is it store.find(Profile, Profile.username == ) or something else? |
| 18:55.26 | niemeyer | hagna: Hard to tell when we don't know your schema/classes |
| 18:55.58 | hagna | niemeyer: oh oops |
| 18:56.21 | hagna | http://www.ravenbrook.com/project/p4dti/tool/cgi/bugzilla-schema/index.cgi?action=range&from=2.18.3&to=3.0&view=View+schema#table-profiles |
| 18:56.49 | hagna | niemeyer: I just want all the objects from that table |
| 18:56.58 | niemeyer | hagna: store.find(Profile) |
| 18:58.06 | hagna | and if I were prematurely optimizing I would select distinct |
| 18:58.18 | hagna | niemeyer: thanks |
| 18:58.30 | niemeyer | hagna: Only if you were incorrectly optimizing :-) |
| 18:58.56 | hagna | maybe |
| 18:59.20 | niemeyer | hagna: For sure.. if you select all rows of one given table, they will always be distinct |
| 18:59.32 | niemeyer | hagna: Unless there's no primary key |
| 19:00.08 | hagna | niemeyer: to be clear I wouldn't select distinct on that table it would be the bugs table for distinct owners of bugs that were open |
| 19:00.33 | hagna | but that's premature with a bug database of only a dozen or so users |
| 19:00.38 | niemeyer | hagna: I'm of course talking about store.find(Profile) |
| 19:00.45 | hagna | niemeyer: yeah |
| 19:00.46 | niemeyer | hagna: Which is where the "and" was connecting to :) |
| 19:01.24 | hagna | I'm lost but the project is 70% done |
| 19:01.36 | niemeyer | Hehehe :) |
| 19:01.50 | niemeyer | Only 30% missing! |
| 19:02.01 | hagna | but the last 10% is just interface bah |
| 19:03.58 | *** join/#storm nephish_ (n=nephish@69.55.30.170) |
| 19:04.07 | nephish_ | hello all. |
| 19:04.44 | nephish_ | is there a command that i can use to reload the attributes of an object from the database in case a value was overwritten by another process? |
| 19:08.52 | *** join/#storm rafael (n=rafael@moinmoin/fan/rafael) |
| 19:11.59 | *** join/#storm Key_Gena104 (i=lok@gateway/tor/x-5389897fa7d5daea) |
| 19:20.09 | radix | nephish_: well, you have to start a new transaction to see that, if you're in SERIALIZABLE transaction mode (which is what you're in if you're using storm) |
| 19:21.05 | radix | nephish_: so store.rollback() or store.commit() will allow you to see those changes that the other process (transaction) made |
| 19:34.35 | nephish_ | ok, store.rollback() fetches values from the database fresh? and commit() updates the db with values, right? |
| 19:34.36 | *** join/#storm leifkb (n=leifkb@dsl82.brbovtma.sover.net) |
| 19:35.02 | nephish_ | radix, but both will update my object ? |
| 19:39.02 | radix | nephish_: commit() commits the transaction meaning your changes get to the database, rollback() rolls back the transaction. the point is that they end the transaction |
| 19:39.32 | radix | nephish_: because the only way to see new changes in SERIALIZABLE-mode transactions is to start a new transaction after the changes have been committed |
| 19:41.21 | nephish_ | ok, my situation is this, one object is waiting for a process to finish that will update a value in the database, if the value is different, then such and such happens. |
| 19:41.47 | nephish_ | i suppose i should commit() and then redeclare ? |
| 19:41.58 | radix | nephish_: redeclare? |
| 19:41.59 | nephish_ | redeclare after the wait |
| 19:42.10 | radix | nephish_: maybe that'd work, whatever it means :-) |
| 19:42.48 | nephish_ | object.commit() wait till process finishes, object = store.get(Object, object.id) |
| 19:43.02 | nephish_ | maybe that is just foolish |
| 19:45.03 | niemeyer | nephish_: Getting the object won't change anything |
| 19:45.15 | niemeyer | nephish_: The object is invalidated on transaction boundaries |
| 19:45.29 | nephish_ | ah |
| 19:45.31 | niemeyer | nephish_: In a way that you can use it again afterwards |
| 19:45.41 | niemeyer | nephish_: and expect new values to be there |
| 19:46.01 | niemeyer | nephish_: rollback and commit won't fetch values from the database |
| 19:46.09 | niemeyer | nephish_: They'll just declare the cached data invalid |
| 19:46.55 | nephish_ | well then i could use sql in a store.execute(sql_statement) i suppose. |
| 19:47.49 | niemeyer | nephish_: Hmm.. |
| 19:47.56 | niemeyer | nephish_: I don't understand your sentence in this context |
| 19:49.13 | radix | it's not *just* about storm's cache, it's also about ending the transaction in the database |
| 19:49.26 | radix | even executing SQL directly, bypassing the cache, wouldn't help you unless you execute a COMMIT or ROLLBACK |
| 19:49.46 | nephish_ | so commit() first, then select ? |
| 19:50.05 | radix | yes, commiting and selecting will definitely get you new data |
| 19:50.14 | niemeyer | I see |
| 19:50.31 | nephish_ | thanks, sorry for the trouble. I know this must be simple sounding from your end. |
| 19:50.32 | radix | although if you already have a reference to the object from before the commit, you don't need to explicitly do the select -- just a note |
| 19:50.40 | niemeyer | nephish_: It's not about Storm.. it's about how SERIALIZABLE transactions work |
| 19:50.44 | radix | nephish_: well, I realize it's not very simple :) |
| 19:50.53 | nephish_ | radix, explicitly, will do. |
| 19:51.25 | niemeyer | nephish_: It also sounds strange that you're committing *just* to do thta |
| 19:51.31 | niemeyer | that |
| 19:51.36 | niemeyer | nephish_: Do you have changes pending? |
| 19:52.09 | nephish_ | gents, how long did it take you to write storm? It amazes me that how simple using a database can be at first glance is, then all these situations come up that call for something.... special |
| 19:52.43 | nephish_ | no changes pending in the main loop, but changes will be executed by the process that the main loop is waiting on. |
| 19:53.13 | radix | nephish_: at this point we've been working on it for, what, a bit over a year? 14 months? |
| 19:53.17 | niemeyer | nephish_: Oh well.. I guess you'll understand it better with some experimentation |
| 19:53.26 | nephish_ | indeed, thanks |
| 19:53.30 | radix | nephish_: really most of the complexity is in understanding databases in the first place |
| 19:53.56 | nephish_ | yeah, i have a huge MySQL manual. It does pretty well. |
| 19:54.11 | niemeyer | nephish_: Hmm.. what engine are you using in your MySQL tables? |
| 19:54.11 | radix | nephish_: if it's got a section on transaction types, read the one about SERIALIZABLE :-) |
| 19:54.17 | radix | oh dear |
| 19:54.20 | nephish_ | ok, cool. |
| 19:54.21 | niemeyer | :-) |
| 19:54.24 | radix | yeah, make sure you use InnoDB :-) |
| 19:54.30 | radix | or do I mean the other one? |
| 19:54.45 | niemeyer | radix: No, that's right |
| 19:54.48 | radix | ok |
| 19:54.56 | nephish_ | really, my boss will buy me any book i tell him i need, i am the only IT guy in the company. Amazon likes me :) |
| 19:54.58 | radix | it's good that I don't even know the name of the bad one :-) |
| 19:55.13 | niemeyer | LOL |
| 19:56.09 | nephish_ | I have most of my tables in InnoDB, a few of the larger history tables are MyISAM, but never read data from them from python, only ruby for the website. |
| 19:56.25 | niemeyer | nephish_: Cool.. so what we said still makes sense :-) |
| 19:56.43 | nephish_ | yes |
| 19:56.46 | nephish_ | thanks |
| 20:54.56 | *** join/#storm Key_Gena104 (i=lok@gateway/tor/x-efb124dd2b8193fa) |
| 21:52.03 | *** join/#storm niemeyer (n=niemeyer@200-103-134-216.ctame705.dsl.brasiltelecom.net.br) |