gtg-contributors team mailing list archive

[Paul Natsuo Kishimoto <mail@xxxxxxxxxxxxxxxxxxx>]

On Tue, 2010-08-03 at 12:46 +0200, Luca Invernizzi wrote:
> On Tue, Aug 3, 2010 at 12:37 PM, Lionel Dricot <ploum@xxxxxxxxx> wrote:
> > On Tue, 3 Aug 2010 12:03:42 +0200, Luca Invernizzi
> > <invernizzi.l@xxxxxxxxx>
> > 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

Attachment: signature.asc
Description: This is a digitally signed message part