On Tue, 2010-08-03 at 12:46 +0200, Luca Invernizzi wrote: > On Tue, Aug 3, 2010 at 12:37 PM, Lionel Dricot <[email protected]> wrote: > > On Tue, 3 Aug 2010 12:03:42 +0200, Luca Invernizzi > > <[email protected]> > > wrote: > >>> Another solution would be, as we currently only store the child IDs, to > >>> not do anything and create the realtionships once the node is added to > >>> the > >>> tree. It means to silently fails when we add a child to a node already > > in > >>> the tree. > >> > >> :) > >> I didn't really get the difference between this last idea and the > >> mechanism already in place in liblarch. Could you explain it? > > > > > > So far, when you add a child_id to a node, the relationship is created and > > both node are updated in the tree. If there's no tree (for example when you > > are building the node in tasktoxml) assigned to the node, an exception is > > raised. > > > > One solution could be to not raise that particular exception and, when a > > node is added to the tree, check if there's already childrens and create > > the relationships at that time. > > > Oh, I thought it was already that way. I like this idea of "delayed > relationship". It seems fairly easy to add (and maintain :)). > Plus, it can be tested easily..
Speaking of work in parallel...I ran into *exactly* this problem last night while hacking on my own dbus-server branch (which I keep in sync by pulling in the liblarch_migration branch periodically). See: http://bazaar.launchpad.net/~gtg-contributors/gtg/dbus-server/revision/855 My approach was what Lionel suggests: * In DataStore.task_factory, a new Task instance (i.e. TreeNode) is added to the tree *immediately* when it is created. * This way, the Task passed to taskxml.task_from_xml() is already associated with a tree, so when add_child() is used, it will not throw exceptions. If the desired child node is not yet loaded (happens often), a pending relationship is created. * MainTree.add_node() changes slightly...see the line: elif not any([id in rel for rel in self._pending_relationships]): * This means that when the child nodes are later added to the tree, if they are part of any pending relationship, then *ONLY* those pending relationships (and no others!) get created. The "pending relationships" concept is very clever and solves this problem easily. I agree that if each backend has task (or tag!) relationships that are *different* from the ones in the DataStore's liblarch tree, it should keep track of these on its own (perhaps even using liblarch for its own tree :D). N.B.: This seems to work for the first-run tasks, where the first node loaded *is* a child of the root, and its children are loaded later. I don't know if it would work in another order. Anyway, I wouldn't suggest merging my whole branch, since there are some other major changes, but please cherry-pick those edits and see if they help. Cheers, -- Paul Kishimoto SM candidate (2012), Technology & Policy Program Massachusetts Institute of Technology http://paul.kishimoto.name — +19053029315
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
