| 00:00.44 | *** join/#storm wallflower (n=wallflow@ip-205-246-113-216.pool.grokthis.net) |
| 00:54.42 | *** join/#storm kov (n=kov@debian/developer/kov) |
| 04:09.16 | *** join/#storm thumper (n=tim@canonical/launchpad/thumper) |
| 05:09.05 | *** join/#storm jukart (n=jukart@194.183.146.178) |
| 05:14.39 | *** join/#storm jrydberg_ (n=johan@212.112.160.94) |
| 06:08.17 | *** join/#storm dobee (n=dobee@lsfw01.lovelysystems.com) |
| 07:28.44 | *** join/#storm goschtl (n=goschtl@p5B0BD034.dip.t-dialin.net) |
| 08:07.06 | *** join/#storm jukart (n=jukart@lsfw01.lovelysystems.com) |
| 08:09.38 | *** join/#storm mcella (n=mcella@ip-179-87.sn2.eutelia.it) |
| 09:44.56 | tlynn | In case anyone here has write access to the tutorial, there's a typo: "code of line -> line of code" |
| 10:47.01 | *** join/#storm goschtl (n=goschtl@p5B0BD034.dip.t-dialin.net) |
| 11:15.22 | tlynn | how do you delete results matching a ResultSet? |
| 11:15.34 | tlynn | rows I should say |
| 11:20.09 | *** join/#storm dobee (n=dobee@lsfw01.lovelysystems.com) |
| 11:20.27 | *** join/#storm andrea-bs (n=andrea@ubuntu/member/beeseek.developer.andrea-bs) |
| 11:32.25 | therve | tlynn: using the remove() method |
| 11:33.52 | tlynn | thanks, is that an alternative to find()? |
| 11:35.05 | tlynn | apparently so. |
| 11:35.28 | therve | hum noe |
| 11:35.36 | tlynn | ah, actually not. you have to do the find first. ok, thanks anyway. |
| 11:35.56 | therve | well, you asked on a ResultSet |
| 11:36.06 | therve | you get ResultSet by calling find() :) |
| 11:36.20 | therve | the remove method of the store is only meant to remove one object |
| 11:36.22 | tlynn | ok, so is there a ResultSet.remove, or do you have to iterate over the RS? |
| 11:37.01 | therve | there is a Result.remove method |
| 11:37.36 | tlynn | a Result? I've not come across those. is there proxying going on when I do e.g. RS.one()? |
| 11:38.11 | tlynn | in other words, how do I get a Result? |
| 11:38.29 | therve | arf arf sorry |
| 11:38.33 | therve | ResultSet.remove |
| 11:39.38 | tlynn | good grief. I've somehow been overlooking that every time I've looked at that class signature in the docs. ok, thanks. |
| 11:45.56 | tlynn | therve: since you seem particularly au fait with storm, what's the best approach for managing transactions? |
| 11:47.25 | therve | tlynn: the same way you would do without storm? |
| 11:47.42 | tlynn | well, I could wrap everything as in: store.commit(), something(), store.commit/rollback() |
| 11:48.06 | tlynn | but then the first store.commit might commit outer stuff. |
| 11:48.24 | tlynn | transactional cursors are the best I've found without storm |
| 11:49.30 | tlynn | I basically don't know how to start-delimit a transactional block in storm |
| 11:49.59 | therve | oh ok |
| 11:50.03 | therve | you don't have to start it |
| 11:50.09 | therve | the first commit is not necessary |
| 11:50.32 | tlynn | but I'd like to be able to assert that nothing else was outstanding at that point |
| 11:50.40 | tlynn | no changes, that is |
| 11:51.11 | tlynn | I don't want a rollback to roll back too much |
| 11:53.52 | tlynn | if I were writing dbapi2 stuff I'd do def f(c=None): if cursor is None: c=new_tx_cursor() // do_something() |
| 11:54.18 | tlynn | which means that I can make the do_something be part of a larger transaction |
| 11:54.37 | tlynn | oops, that should say "if c is None" |
| 11:54.48 | tlynn | I'll do the same here I think |
| 11:56.07 | tlynn | hmm, maybe not. I'm supposed to trust the store after all. |
| 12:08.19 | radix | <tlynn> but I'd like to be able to assert that nothing else was outstanding at that point |
| 12:08.42 | radix | unfortunately there's no begin() method |
| 12:09.46 | tlynn | I guess the best policy is just to cross my fingers and hope then :-) |
| 12:10.05 | tlynn | and do a commit after every write |
| 12:10.39 | radix | tlynn: if you're making some sort of service, you should basically commit after every request |
| 12:10.58 | radix | tlynn: if you want to be extra careful, you can .rollback() at the beginning |
| 12:11.17 | radix | which would ensure that nothing else gets committed accidentally, but doesn't tell you if there is uncommitted stuff |
| 12:11.35 | tlynn | hmm, not sure whether .commit at the start or .rollback is worse. :-) |
| 12:12.46 | tlynn | I think you're right though, to get the speed advantages I should only commit at the end of every successful webpage view |
| 12:13.03 | radix | I don't suggest that for speed |
| 12:13.18 | radix | but rather the semantics |
| 12:13.21 | tlynn | well, as an alternative to committing after every change |
| 12:13.49 | radix | you should have try: handle_request(); except: store.rollback(); else: store.commit() |
| 12:14.06 | tlynn | yep, that seems the best |
| 12:14.16 | radix | so that a request is all or nothing as far as data manipulation goes |
| 12:14.44 | tlynn | it's still unpleasant though, since it makes the test code have to do the same thing |
| 12:14.50 | radix | not really |
| 12:15.07 | radix | our test code in landscape doesn't call commit at all, in the common case |
| 12:15.54 | radix | you can still inspect the data that was inserted/manipulated by a particular piece of code by doing a query on the store |
| 12:16.09 | radix | just make sure you're using the same store in your tests that your app code is using |
| 12:16.15 | tlynn | I suppose that's fine. I'd prefer to let other code pretend there's no database there, but this is close enough |
| 12:16.25 | radix | I'm not sure what you mean |
| 12:16.52 | radix | you don't want your unit tests to know about the store? |
| 12:17.39 | tlynn | no, the tests were a red herring, but this means that the request handling code knows about commit/rollback logic. as you've said, it's a sensible boundary for it though, so all's well. |
| 12:17.53 | radix | only one part of it, and if you have a decent web framework, it's hookable :) |
| 12:18.23 | radix | or with a wrapper or something, so you don't need to hack your core web request handling logic if you don't want to |
| 12:18.46 | radix | both twisted.web and zope can be hooked into to add transaction stuff pretty easily |
| 12:19.32 | tlynn | yep. some kind of abstract persistence.open() and persistence.close() is good enough. |
| 12:19.47 | tlynn | alas I'm using the web framework that is cgi |
| 12:20.30 | tlynn | on a codebase that dates back to python 1.5 |
| 13:12.55 | *** join/#storm kov (n=kov@debian/developer/kov) |
| 14:35.31 | *** part/#storm goschtl (n=goschtl@p5B0BD034.dip.t-dialin.net) |
| 16:06.28 | *** join/#storm nullie (n=ilya@87.254.150.141) |
| 17:21.30 | *** join/#storm jukart (n=jukart@85-124-221-45.static.xdsl-line.inode.at) |
| 17:49.35 | *** join/#storm rockstar (n=rockstar@75-171-142-52.hlrn.qwest.net) |
| 18:22.13 | *** join/#storm jukart (n=jukart@85-124-221-45.static.xdsl-line.inode.at) |
| 18:34.19 | *** join/#storm dobee (n=dobee@85-124-200-100.static.xdsl-line.inode.at) |
| 18:47.29 | *** join/#storm bigdo2 (n=scmikes@72-197-8-8-arpa.cust.cinci.current.net) |
| 19:13.30 | *** join/#storm thumper (n=tim@canonical/launchpad/thumper) |
| 19:26.12 | *** join/#storm dobee (n=dobee@213162066151.public.t-mobile.at) |
| 23:24.17 | *** join/#storm kov (n=kov@debian/developer/kov) |