gtg-contributors team mailing list archive

[Lionel Dricot <ploum@xxxxxxxxx>]

On Tue, 3 Aug 2010 11:44:07 +0200, Luca Invernizzi
<invernizzi.l@xxxxxxxxx>
wrote:
> On Tue, Aug 3, 2010 at 10:28 AM, Lionel Dricot <ploum@xxxxxxxxx> wrote:
>> Hi,
>>
>> This question is mainly for Luca.
>>
>> Currently, we are building a task object (including all the
>> relationships)
>> then, the backend push that task in the datastore.
>>
>> Does it makes more sense to, instead, make the backend pushing tasks
and
>> relationships separately ? Current crash in the liblarch_migration
branch
>> is due to the fact that we try to create the relationship inside the
task
>> while that task has not yet been added to a tree.
> 
> That's a possibility. The problem is that the backends that have
> relationship between tasks are likely to store that information inside
> their task object, so the backend should take care of caching that
> information.
> An easier approach would be one that I've already tested for the
> couchdb backend:
> 
> - the backend fetches a task to push
> - if the task Z has a non-yet-loaded parent/child A, it creates a
> stub-task (an empty task with the id of A) and sets its modification
> time to the very very past.
> - when the real A is loaded by the backend, it updates the  stub version
> of A


Speaking of experience : WRONG IDEA.

I mean, I had exactly the same idea and GTG was using that until 0.2.3.
And it's definitely a huge pain. We should avoid that, really.

Also, there is already such a mechanism in liblarch : if you create a
relationship and one of the node is not already existing, this relationship
is put on a queue until both nodes are available. Problem is that, at the
time we create the task, we don't have any tree yet !

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.



> This way, the backend does not need to store information about
> relationships and the tree relationships are always between loaded
> tasks.
> Problem is that we might have "(New Task)" objects popping up while
> loading the tasks. Maybe we could resolve that via a filter?
> 
> 
> 
>>
>>
>> >From a liblarch perspective, it means exposing the new_relationship
>> function. To me, it also makes some sense as I'm trying to have all
that
>> relationship stuffs completely out of the task and maintened only in
the
>> tree (the rationale behind it is that relationship is function of the
>> filters and that I want to unify everything as being a view of a tree,
>> removing the concept of the "real tree" and "real relationships". A
nice
>> side effect would be that a node could be part of multiple trees)
>>
>> I'm currently coding that to see how it works but I'm not familiar with
>> the @decorator.
>>
>> Lionel
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~gtg-contributors
>> Post to     : gtg-contributors@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~gtg-contributors
>> More help   : https://help.launchpad.net/ListHelp
>>