| 00:33.26 | *** join/#storm mikex2 (n=mikael@193.11.22.216) |
| 00:42.32 | *** join/#storm oubiwann (n=oubiwann@c-24-8-208-199.hsd1.co.comcast.net) |
| 00:52.34 | *** join/#storm artista_frustrad (n=artista_@201-24-231-134.ctame704.dsl.brasiltelecom.net.br) |
| 00:53.41 | *** join/#storm oubiwann (n=oubiwann@c-24-8-208-199.hsd1.co.comcast.net) |
| 01:07.18 | *** join/#storm oubiwann (n=oubiwann@c-24-8-208-199.hsd1.co.comcast.net) |
| 01:12.27 | *** join/#storm oubiwann (n=oubiwann@c-24-8-208-199.hsd1.co.comcast.net) |
| 01:14.24 | *** join/#storm gabriel_ (n=gabriel@74.198.8.59) |
| 05:47.00 | *** join/#storm stub (n=stub@ppp-58-8-12-35.revip2.asianet.co.th) |
| 06:26.44 | *** join/#storm jukart (i=lovely@81.189.156.94) |
| 06:37.06 | *** join/#storm gabriel_ (n=gabriel@CPE000d889fa6da-CM0016b533fdcc.cpe.net.cable.rogers.com) |
| 10:27.18 | *** join/#storm mikex2 (n=mikael@193.11.22.216) |
| 10:51.29 | *** join/#storm philiKON (n=philiKON@gw-trusted.physics.gla.ac.uk) |
| 11:24.00 | jamesh | philiKON: fwiw, I haven't done any work on the other bug I pointed at. |
| 11:24.09 | philiKON | hi jamesh |
| 11:24.16 | philiKON | jamesh: yeah, that's fine |
| 11:24.27 | philiKON | i suppose i could deal with it while i'm at it |
| 11:24.50 | philiKON | i've got it working for ReferenceSet, except for .add() and .remove() |
| 11:25.09 | philiKON | i need to understadn Relation.link() and .unlink() first |
| 11:26.06 | philiKON | btw, what does the .clear() method on a ReferenceSet do exactly? |
| 11:26.19 | jamesh | philiKON: the main purpose of those bits of code are to (1) cache the relationship where it makes sense, and (2) keep strong references on yet-to-be-flushed objects |
| 11:27.02 | jamesh | in the example I gave for (2), with unconstrained reference sets, a reference to "bar" would be retained and it would be automatically added to the store when "foo" was. |
| 11:27.32 | jamesh | the idea being that you can pretty much forget about "bar" and it will make it into the database as expected |
| 11:27.46 | philiKON | right |
| 11:28.20 | jamesh | one of the big problems with implementing constrained references and referencesets is the caching |
| 11:28.23 | *** join/#storm danilo_ (n=danilo@static-213-198-236-193.adsl.eunet.rs) |
| 11:28.51 | jamesh | for the unconstrained ones, there are pretty simple rules to tell when the relationship has been broken |
| 11:28.51 | philiKON | how so |
| 11:29.08 | philiKON | right, true |
| 11:29.22 | philiKON | but somebody could do bar.qualifier=something_else and the relationship breaks |
| 11:29.37 | jamesh | and ideally Storm would notice that. |
| 11:29.47 | philiKON | right |
| 11:30.47 | philiKON | dang, this is much more complicated than i anticipated :) |
| 11:31.00 | philiKON | my use case really just involves qualified/constrained many-to-many relations |
| 11:31.04 | philiKON | for now at least |
| 11:31.39 | philiKON | so anyway, how would storm be able to notice this? is there a hook for this? |
| 11:34.44 | jamesh | so, each storm object has an ObjectInfo structure behind the scenes |
| 11:35.09 | jamesh | that ObjectInfo has an EventSystem that emits a "changed" signal when properties are updated |
| 11:36.14 | jamesh | the Relation code hooks this signal to detect when the columns involved in the relation change |
| 11:37.01 | philiKON | i see |
| 11:37.15 | philiKON | so ideally it would also hook into the changed signal for the constrained column |
| 11:38.42 | jamesh | well, the hook function will be called for all column changes for that object |
| 11:38.50 | jamesh | the difficult part is deciding which changes matter |
| 11:39.32 | philiKON | well... the Relation object knows about the constraints |
| 11:39.47 | philiKON | so it could look at the object and see if its data changed, no? |
| 11:40.34 | jamesh | this will really depend on how the constraints are defined. |
| 11:40.34 | philiKON | i mean, the important data |
| 11:41.22 | jamesh | one option I've haven't really investigated was to treat the extra constraints like pseudo columns |
| 11:42.06 | jamesh | for example, would it make sense to define the set from my bug comment as between (Foo.id, 42) and (Bar.foo_id, Bar.qualifier)? |
| 11:42.40 | jamesh | it would only handle equality qualifiers, but would be pretty easy to interpret ... |
| 11:43.58 | philiKON | i'm not sure i'm following |
| 11:44.58 | jamesh | you know that References and ReferenceSets can use multiple columns rather than a single local and remote column? |
| 11:45.16 | philiKON | i didn't |
| 11:45.24 | jamesh | well, you can :) |
| 11:45.29 | philiKON | he good to know |
| 11:45.44 | jamesh | so what if some of the columns you define on either side are actually constants? |
| 11:46.00 | philiKON | good point |
| 11:46.28 | philiKON | would be a bit difficult to interpret for strings |
| 11:46.33 | philiKON | is it a class id? |
| 11:46.36 | philiKON | or a value? |
| 11:46.52 | jamesh | that's a point I haven't considered. |
| 11:47.36 | jamesh | but for the many to many set, you could potentially do something like ReferenceSet((Local.id, 42), (Link.local_id, Link.qualifier), Link.remote_id, Remote.id) |
| 11:47.39 | philiKON | i smell a "storm injection" ;) |
| 11:47.58 | philiKON | yes |
| 11:49.00 | philiKON | the question is whether that'd be any easier on the implementation in .add(), .remove() etc. |
| 12:04.51 | *** join/#storm niemeyer (n=niemeyer@189.73.142.161) |
| 12:18.26 | *** join/#storm fcorrea (n=fcorrea@187.3.137.148) |
| 13:20.08 | *** join/#storm danilo_ (n=danilo@static-213-198-236-193.adsl.eunet.rs) |
| 13:34.55 | philiKON | jamesh: i've been musing on this some more and as far as i can tell, your idea wouldn't be any simpler to implement than what we've got now. correct me if i'm wrong, though :) |
| 13:35.16 | philiKON | and considering the syntax, i think i'd prefer staying clear of more parentheses |
| 13:36.30 | philiKON | in the end, of course, i just care about getting my use case working, so i'll go with whatever syntax you guys like best |
| 13:41.16 | *** join/#storm oubiwann (n=oubiwann@c-24-8-208-199.hsd1.co.comcast.net) |
| 13:59.03 | *** join/#storm oubiwann (n=oubiwann@c-24-8-208-199.hsd1.co.comcast.net) |
| 14:05.30 | *** join/#storm oubiwann (n=oubiwann@c-24-8-208-199.hsd1.co.comcast.net) |
| 16:00.40 | *** join/#storm oubiwann_ (n=oubiwann@c-24-8-208-199.hsd1.co.comcast.net) |
| 16:28.26 | *** join/#storm mikex2 (n=mikael@193.11.22.216) |
| 17:10.41 | *** join/#storm jukart (n=jukart@d86-32-163-51.cust.tele2.at) |
| 17:17.09 | *** join/#storm andrea-bs (n=andrea@ubuntu/member/beeseek.developer.andrea-bs) |
| 18:22.22 | *** join/#storm jukart (n=jukart@d86-32-163-51.cust.tele2.at) |
| 18:25.08 | *** join/#storm jukart_ (i=lovely@81.189.156.94) |
| 18:27.36 | *** join/#storm jukart__ (n=jukart@d86-32-163-51.cust.tele2.at) |
| 18:36.04 | *** join/#storm kapil__ (n=kapil@pool-74-96-4-147.washdc.east.verizon.net) |
| 18:44.25 | *** join/#storm philiKON (n=philiKON@cpc3-broo2-0-0-cust103.renf.cable.ntl.com) |
| 18:56.16 | *** join/#storm danilo_ (n=danilo@cable-94-189-247-236.dynamic.sbb.rs) |
| 20:30.51 | *** join/#storm danilos (n=danilo@static-213-198-236-193.adsl.eunet.rs) |
| 21:01.13 | *** join/#storm philiKON (n=philiKON@cpc3-broo2-0-0-cust103.renf.cable.ntl.com) |
| 22:06.38 | *** join/#storm mikex2 (n=mikael@193.11.22.216) |
| 23:10.54 | *** join/#storm oubiwann (n=oubiwann@c-24-8-208-199.hsd1.co.comcast.net) |
| 23:24.50 | *** join/#storm oubiwann (n=oubiwann@c-24-8-208-199.hsd1.co.comcast.net) |
| 23:37.26 | *** join/#storm oubiwann (n=oubiwann@c-24-8-208-199.hsd1.co.comcast.net) |