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