gtg-contributors team mailing list archive

[Paul Natsuo Kishimoto <mail@xxxxxxxxxxxxxxxxxxx>]

On Tue, 2010-08-03 at 16:01 +0200, Luca Invernizzi wrote:
> >  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.
> 
> From my "backendish" point of view, that solution is not a good one.
> Any internet-based backend will take a few seconds to build a task,
> and it can happend that something goes wrong (connection is lost...).
> I've written the backends with the idea that if anything went wrong I
> could throw away the task easily (because it does not have connections
> with any other task yet). Plus, the user would see an empty task pop
> up, that after a few seconds gets a title, after a few more a due
> date... This means that tasks would "misterously" disappear from the
> workview.

  Hmm...I see what you mean. To deal with latency, can the backend take
the time to assemble the necessary data, and only contact the
task_factory once it is sure it will be able to finish the operation?

  To me, this would be the easier way to insulate against UI phantoms
and other weird stuff.

  If you guys have experience with SQL, you will know about BEGIN
TRANSACTION / COMMIT / ROLLBACK.

  A client to the database can start with "BEGIN TRANSACTION" and start
doing all kinds of SQL (multiple statements and queries). If "ROLLBACK"
is given, everything since "BEGIN TRANSACTION" is removed, and to other
database clients it looks like nothing ever happened. If "COMMIT" is
given, the other clients see the update as if it happened
instantaneously (it is "atomic").

  Basically what you are discussing is making task creation a
transaction — get a empty task, then populate it (including
relationships), then commit it (success) or roll it back (connection
fails). My feeling is that supporting that behaviour would be much more
complex than filling a bunch of variables in the backend code, before
creating the Task.

-- 
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