00:00.20 | *** join/#storm wallflower (n=wallflow@ip-205-246-113-216.pool.grokthis.net) |
05:57.13 | *** join/#storm MFen (n=cdodt@demo.goonmill.org) |
05:57.23 | MFen | o,O |
05:57.50 | MFen | easy_install storm installs a package named 'rdf'.. what's that about? i know what rdf is, i'm just curious what storm uses it for |
05:58.40 | MFen | wait, never mind. that's not what i'm seeing at all. something else installed it |
06:01.10 | MFen | confusing setuptools output is all. |
06:11.24 | *** join/#storm Tetracomm (n=nicholas@72.252.29.2) |
06:11.29 | *** part/#storm Tetracomm (n=nicholas@72.252.29.2) |
06:12.22 | *** join/#storm oubiwann (n=oubiwann@67.111.52.130.ptr.us.xo.net) |
06:22.14 | *** join/#storm jukart (i=lovely@lsfw01.lovelysystems.com) |
06:46.42 | *** part/#storm MFen (n=cdodt@demo.goonmill.org) |
08:53.07 | *** join/#storm oubiwann (n=oubiwann@67.111.52.130.ptr.us.xo.net) |
08:54.44 | *** join/#storm mcella (n=mcella@ip-142-254.sn3.eutelia.it) |
09:57.48 | *** join/#storm goschtl (n=goschtl@p5B0BFC48.dip.t-dialin.net) |
09:59.18 | *** join/#storm lightyear (n=ben@o.bcn.fluendo.net) |
12:51.25 | *** join/#storm goschtl (n=goschtl@p5B0BFC48.dip.t-dialin.net) |
13:16.01 | *** join/#storm Sidnei (n=Sidnei@plone/dreamcatcher) |
13:17.57 | *** join/#storm Sidnei (n=Sidnei@plone/dreamcatcher) |
13:22.19 | *** join/#storm kov (n=kov@debian/developer/kov) |
14:35.14 | *** join/#storm HazzaUK (n=hwaye@dsl-217-155-201-84.zen.co.uk) |
15:04.11 | *** join/#storm sidnei (n=sidnei@200-203-1-234.cslce701.dsl.brasiltelecom.net.br) |
16:07.29 | *** join/#storm jjrojo (n=jjrojo@239.Red-81-47-156.staticIP.rima-tde.net) |
16:31.39 | *** join/#storm Sidnei (n=Sidnei@plone/dreamcatcher) |
16:32.19 | *** join/#storm Sidnei (n=Sidnei@plone/dreamcatcher) |
16:32.38 | *** join/#storm vvinet (n=vince@modemcable188.10-70-69.static.videotron.ca) |
16:46.24 | *** join/#storm jamesh_ (n=james@canonical/launchpad/jamesh) |
16:51.32 | *** join/#storm kov (n=kov@debian/developer/kov) |
16:53.33 | *** join/#storm oubiwann (n=oubiwann@67.111.52.130.ptr.us.xo.net) |
16:56.30 | *** join/#storm niemeyer (n=niemeyer@67.111.52.130.ptr.us.xo.net) |
16:57.11 | *** join/#storm jkakar (n=jkakar@67.111.52.130.ptr.us.xo.net) |
17:00.51 | Sidnei | hey there jkakar, niemeyer |
17:01.21 | jkakar | Heya Sidnei! |
17:01.35 | niemeyer | Sidnei! |
17:01.45 | niemeyer | Sidnei: Just bootstrapping the sprint :) |
17:02.20 | Sidnei | niemeyer: neat. too bad i'm missing the fun. |
17:02.47 | jkakar | Sidnei: Not for long! |
17:03.03 | Sidnei | indeed, indeed. |
17:47.10 | *** join/#storm jamesh__ (n=james@canonical/launchpad/jamesh) |
17:59.21 | *** join/#storm kov (n=kov@debian/developer/kov) |
18:14.37 | *** join/#storm HazzaUK (n=hwaye@dsl-217-155-201-84.zen.co.uk) |
18:28.06 | HazzaUK | Whats the word on lazy values and the twisted-integration? I'm using the a StorePool to maintain a pool of transactions. I have a hook to emit on add/update/remove of objects after flushing. These emitted objs are stored by its listeners. I when want to disassociate these with the store from which they came. |
18:28.37 | HazzaUK | with/from |
18:29.28 | HazzaUK | I assume this is what invalidate is for? Its not provided by DeferredStore though. |
18:32.16 | *** join/#storm HazzaUK (n=hwaye@dsl-217-155-201-84.zen.co.uk) |
18:37.38 | *** join/#storm HazzaUK (n=hwaye@dsl-217-155-201-84.zen.co.uk) |
18:38.15 | HazzaUK | did anyone see my previous messages or should I spew again? |
18:40.28 | therve | HazzaUK: I saw it |
18:40.37 | HazzaUK | cool |
18:40.37 | therve | HazzaUK: I'm not sure what I can tell you :) |
18:40.48 | HazzaUK | :( |
18:41.01 | therve | HazzaUK: what do you mean by "disassociate" with the store? |
18:41.20 | therve | it's not the point of invalidate |
18:43.14 | HazzaUK | yeah I'm not really sure what its for... When I say disassociate I mean remove anything from the store cache relating to that obj. |
18:43.40 | therve | HazzaUK: why do you want to do that? |
18:43.50 | therve | the cache is cleaned after commit/rollback |
18:47.13 | HazzaUK | My problem is that I'm getting requests to reget/find the obj as lazy value resolution doesn't work. I'm not really sure what I have to do to unlazyfy the objs variables, and I don't want to reget/find |
18:48.26 | therve | how do you get the objects in the first place? |
18:49.29 | HazzaUK | By getting a store from the pool, and add/get/finding them. Then these obj are emitted on flush via the flush hooks |
18:51.28 | HazzaUK | then the store is put back in to the pool |
18:51.51 | *** join/#storm jamesh_ (n=james@canonical/launchpad/jamesh) |
18:52.38 | therve | yeah I don't know |
18:53.03 | therve | it may not be really hard to build a custom thing |
18:53.16 | HazzaUK | I could take out a dedicated store for each listener |
18:53.32 | HazzaUK | but that seems wasteful |
18:53.43 | therve | right that doesn't seem lik the right choice |
18:55.24 | HazzaUK | I'm not sure how the lazy value resolution works. Could you fill me in? |
18:58.01 | therve | well, when you commit/rollback, it changes every variables to LazyValue |
18:58.15 | therve | so when you access it the next time it tries to resolve it in __get__ |
18:59.02 | HazzaUK | These emitted objs are only meant to be treated as read only so perhaps have one store for these read only objects that they get associated with after the store is put back in to the pool? |
18:59.43 | HazzaUK | And I've seem AutoReload somewhere. What exactly does this do? |
19:00.40 | HazzaUK | Could I at the same time make these objs variables autoreloadable (assuming this means when changes are commited to the db they are reflected in these variables) |
19:01.26 | HazzaUK | So this read only store would act as an consistent representation of the underlying db |
19:04.03 | HazzaUK | meep |
19:38.32 | *** join/#storm kripken_ (n=alon@85.250.58.150) |
21:53.38 | vvinet | is the initialization of a store heavy? |
21:53.58 | vvinet | I am wondering if it is better to create a pool of stores to dispatch them to threads |
21:54.15 | vvinet | or just create a store when a thread requests it, and let it be garbage collected afterwards |
22:11.09 | therve | vvinet: creating a store creates a connection to your database |
22:11.23 | therve | vvinet: it's generally nice to keep control of that number using a pool |
22:11.52 | vvinet | hmmk |
22:12.19 | vvinet | that's what I had concluded by digging a bit in the docs |
22:12.29 | vvinet | so if I constantly re-use the stores |
22:12.36 | vvinet | will they eventually grow bigger and bigger |
22:12.51 | vvinet | if the threads that use them do not store.remove() the objects |
22:13.07 | vvinet | oh nvm |
22:13.11 | vvinet | store.remove is a delete haha |
22:28.15 | *** join/#storm niemeyer (n=niemeyer@67.111.52.130.ptr.us.xo.net) |
22:49.47 | *** join/#storm kov (n=kov@debian/developer/kov) |
23:42.42 | *** join/#storm Sidnei_ (n=Sidnei@200-96-117-14.cslce701.dsl.brasiltelecom.net.br) |