| 00:01.06 | *** join/#storm wallflower (n=wallflow@ip-205-246-113-216.pool.grokthis.net) |
| 00:10.03 | *** join/#storm johan (n=jdahlin@201-68-7-115.dsl.telesp.net.br) |
| 00:10.04 | *** join/#storm jdahlin (n=jdahlin@201-68-7-115.dsl.telesp.net.br) |
| 02:38.27 | *** join/#storm johan (n=jdahlin@201-68-7-115.dsl.telesp.net.br) |
| 02:39.14 | *** join/#storm jdahlin_ (n=jdahlin@201-68-7-115.dsl.telesp.net.br) |
| 02:56.46 | *** join/#storm johan (n=jdahlin@201-68-7-115.dsl.telesp.net.br) |
| 03:02.16 | *** join/#storm jdahlin_ (n=jdahlin@201-68-7-115.dsl.telesp.net.br) |
| 04:52.26 | *** join/#storm jdahlin__ (n=jdahlin@201-68-7-115.dsl.telesp.net.br) |
| 04:53.03 | *** join/#storm jdahlin (n=jdahlin@201-68-7-115.dsl.telesp.net.br) |
| 05:22.16 | *** join/#storm jukart (n=jukart@lsfw01.lovelysystems.com) |
| 05:23.09 | *** join/#storm jukart (n=jukart@lsfw01.lovelysystems.com) |
| 05:32.00 | *** join/#storm dobee (n=dobee@lsfw01.lovelysystems.com) |
| 05:59.29 | *** join/#storm johan (n=jdahlin@201-68-7-115.dsl.telesp.net.br) |
| 05:59.35 | *** join/#storm jdahlin_ (n=jdahlin@201-68-7-115.dsl.telesp.net.br) |
| 06:40.37 | *** join/#storm jdahlin__ (n=jdahlin@201-68-7-115.dsl.telesp.net.br) |
| 06:41.01 | *** join/#storm jdahlin (n=jdahlin@201-68-7-115.dsl.telesp.net.br) |
| 07:06.56 | *** join/#storm goschtl (n=goschtl@p5B0BC11F.dip.t-dialin.net) |
| 08:43.33 | *** join/#storm lightyear (n=ben@nat/fluendo/x-5339d067bacf39e3) |
| 11:11.00 | *** join/#storm kov (n=kov@debian/developer/kov) |
| 11:27.41 | *** join/#storm andrea-bs (n=andrea@ubuntu/member/beeseek.developer.andrea-bs) |
| 11:42.29 | jrydberg_ | therve: there? |
| 11:43.26 | therve | yep |
| 11:43.48 | jrydberg_ | how come store.start() return a deferred? |
| 11:44.19 | therve | probably for a good reason |
| 11:44.26 | therve | I think it creates a connection |
| 11:46.19 | jrydberg_ | what's the normal pattern using twisted+storm in a request based application? |
| 11:46.28 | jrydberg_ | have a StorePool and get a new store for each request? |
| 11:47.22 | therve | there is no pattern, because I never used it |
| 11:47.42 | *** join/#storm niemeyer (n=niemeyer@200-181-177-142.ctame705.dsl.brasiltelecom.net.br) |
| 11:48.29 | therve | so yeah, store.start returns a Deferred because it creates the connection to the db |
| 11:48.47 | niemeyer | Good morning! |
| 11:49.32 | therve | jrydberg_: but if you use a pool, you won't get a "new" store for each request |
| 11:49.38 | therve | you'll ask a store to the pool |
| 11:50.35 | jrydberg_ | but should you think of stores as of cursors in the dbapi? |
| 11:52.33 | therve | a sotre is more a connection |
| 11:53.55 | therve | niemeyer: when you have some time, I'd like to discuss a problem I've found |
| 11:54.11 | therve | (http://paste.ubuntu.com/53148/) |
| 11:56.55 | niemeyer | therve: What is it? |
| 11:57.03 | *** join/#storm jdobrien (n=jdobrien@238.205.119.70.cfl.res.rr.com) |
| 11:59.17 | therve | niemeyer: ok that's not easy to explain :) |
| 11:59.35 | therve | niemeyer: you have an object in the store cache |
| 12:00.00 | therve | niemeyer: with a field 'title' with value 'x' |
| 12:00.14 | niemeyer | therve: Yeah, different Stores have different objects |
| 12:00.17 | therve | niemeyer: in another store, the field 'title' is updated to value 'y' |
| 12:00.27 | niemeyer | therve: Because they have different connections, which may actually represent objects in different ways |
| 12:00.45 | niemeyer | therve: I'm just wondering if there's an actual issue I'm not identifying |
| 12:00.49 | therve | niemeyer: if in the original object, you update the value to 'x' again (even after a commit) |
| 12:01.10 | therve | niemeyer: the value in the db stays at 'y' |
| 12:01.21 | therve | niemeyer: this is a real problem I experienced in landscape |
| 12:01.35 | therve | niemeyer: the test case I pasted should show that |
| 12:02.06 | niemeyer | therve: So what happens with that test? |
| 12:02.17 | therve | niemeyer: the last assertion fails |
| 12:02.47 | therve | title is still equal to "Title 40" |
| 12:03.15 | niemeyer | therve: Ok, let me try to reproduce.. where's this test located? |
| 12:03.24 | therve | oh right |
| 12:03.32 | therve | niemeyer: in tests/store/base.py |
| 12:04.12 | therve | niemeyer: http://paste.ubuntu.com/53171/ |
| 12:04.13 | therve | diff |
| 12:04.36 | niemeyer | therve: return function(*args, **kwargs) |
| 12:04.36 | niemeyer | OperationalError: database is locked |
| 12:04.44 | niemeyer | therve: That's what I get with sqlite |
| 12:04.53 | therve | niemeyer: right that doesn't work with sqlite |
| 12:04.57 | therve | niemeyer: try with postgres |
| 12:05.38 | niemeyer | therve: Ok, reproduced, let me understand what's going on |
| 12:06.01 | therve | niemeyer: and this is the fix I've tried: http://paste.ubuntu.com/53172/ |
| 12:17.20 | niemeyer | therve: Interesting bug |
| 12:18.33 | therve | niemeyer: as much as a bug can be interesting, yes :) |
| 12:18.46 | niemeyer | therve: Well, bugs can be boring too |
| 12:19.02 | therve | niemeyer: right |
| 12:21.16 | therve | niemeyer: fwiw, I realised the problem on a page that updated a boolean field |
| 12:21.40 | therve | niemeyer: by switching a lot between true/false, I managed to trigger the problem |
| 12:22.16 | therve | I *hope* that's what is shown in the test, but I'm not 100% sure it's the exact same one |
| 12:22.50 | niemeyer | therve: Well, that's definitely a serious bug.. it was a great catch |
| 12:24.31 | therve | nothing beats careful reviews... |
| 12:28.24 | niemeyer | therve: I *think* that this is the fix we want: http://paste.ubuntu.com/53177/ |
| 12:29.35 | niemeyer | Or, more clearly: http://paste.ubuntu.com/53178/ |
| 12:31.22 | niemeyer | therve: The checkpointed value reflects the value we think is in the database.. the issue in this case is specifically that we're not checkpointing when we invalidate an object |
| 12:31.54 | niemeyer | therve: Objects are invalidated when we don't know their state for usre |
| 12:31.55 | niemeyer | sure |
| 12:32.52 | therve | niemeyer: yep that looks like a good solution |
| 12:33.32 | niemeyer | therve: The main difference between that and the previous solution is that this will keep the behavior of not doing updates when we go back and forth between values |
| 12:33.53 | therve | niemeyer: ah right that's what I was wondering |
| 12:38.33 | niemeyer | therve: Are you going to prepare a fix for this one? |
| 12:39.44 | therve | niemeyer: you mean creating a branch with my test an your fix? |
| 12:40.13 | niemeyer | therve: Yeah, and perhaps a comment next to the = Undef explaining why we have to checkpoint it |
| 12:40.27 | niemeyer | therve: Well, why we have to reset the checkpointing there |
| 12:40.35 | niemeyer | therve: I guess we'll have to disable the test in sqlite too |
| 12:40.41 | therve | niemeyer: yep, I'll do that |
| 12:40.52 | niemeyer | therve: Cool, thanks a lot for finding this one and fixing it |
| 12:40.59 | niemeyer | therve: Let's prepare 0.14 |
| 12:41.24 | therve | niemeyer: what about the problem reporter by James? |
| 12:41.54 | therve | s/reporter/reported |
| 12:50.05 | niemeyer | therve: We have to fix it too |
| 12:51.32 | therve | niemeyer: I didn't finish the tests for that, but it didn't have an impact on the performance of our test suite |
| 12:51.52 | niemeyer | therve: Sweet, that's cool |
| 12:59.07 | *** join/#storm jdahlin_ (n=jdahlin@201-68-7-115.dsl.telesp.net.br) |
| 13:05.20 | *** join/#storm jdahlin_ (n=jdahlin@201-68-7-115.dsl.telesp.net.br) |
| 13:43.37 | weatherman | storm/277095-update-cache r270 committed by thomas@canonical.com |
| 13:43.37 | weatherman | Reset checkpoint states of variables when updating a field with a lazy value: |
| 13:43.38 | weatherman | this fixes a problem with an update reverting a field value to a previously |
| 13:43.42 | weatherman | cached value. |
| 13:45.10 | weatherman | storm/277095-update-cache r271 committed by thomas@canonical.com |
| 13:45.10 | weatherman | Update C extension with the same fix as variables.py |
| 14:58.57 | weatherman | storm/270893-variable-hash r270 committed by thomas@canonical.com |
| 14:58.57 | weatherman | Remove __hash__ and __eq__ methods of Variable, and change the way objects are |
| 14:58.58 | weatherman | stored in the cache, using get(to_db=True) instead of hashing Variable |
| 14:59.02 | weatherman | instances. |
| 15:01.23 | weatherman | storm/270893-variable-hash r271 committed by thomas@canonical.com |
| 15:01.23 | weatherman | Remove tp_hash and tp_richcompare in the C implementation of Variable. |
| 15:03.35 | *** join/#storm kov (n=kov@debian/developer/kov) |
| 15:27.48 | *** join/#storm andrea-bs (n=andrea@ubuntu/member/beeseek.developer.andrea-bs) |
| 15:36.49 | weatherman | storm/270893-variable-hash r272 committed by thomas@canonical.com |
| 15:36.49 | weatherman | Make tests/expr.py not rely on Variable.__eq__ |
| 15:47.42 | weatherman | storm/270893-variable-hash r273 committed by thomas@canonical.com |
| 15:47.42 | weatherman | Fix other tests relying on variables with same value being equal. |
| 16:51.53 | *** join/#storm sidnei (n=Sidnei@201.35.187.219) |
| 17:10.54 | *** join/#storm rockstar` (n=rockstar@c-75-71-193-91.hsd1.co.comcast.net) |
| 17:31.26 | *** join/#storm dobee (n=dobee@85-124-200-100.static.xdsl-line.inode.at) |
| 17:36.01 | *** join/#storm jamesh_ (n=james@canonical/launchpad/jamesh) |
| 18:43.43 | *** join/#storm sidnei_ (n=Sidnei@200-203-77-184.cslce701.dsl.brasiltelecom.net.br) |
| 20:26.47 | *** join/#storm dobee (n=dobee@85-124-200-100.static.xdsl-line.inode.at) |
| 21:05.38 | *** join/#storm jamesh_ (n=james@canonical/launchpad/jamesh) |
| 21:06.18 | *** join/#storm jdobrien (n=jdobrien@238.205.119.70.cfl.res.rr.com) |
| 21:41.58 | *** join/#storm oubiwann (n=oubiwann@97-119-87-228.omah.qwest.net) |