Version support for datastore/Progress

From Sugar Labs
< Version support for datastore
Revision as of 16:57, 2 June 2009 by Sascha silbe (talk | contribs) (report on progress)
Jump to navigation Jump to search

Time line

For reference, I've copied the timeline from the proposal.

Application deadline
Easter (sunday); UI mockup submitted for review by Design Team
start of (university) term; announcement of accepted GSoC proposals
submitted API draft for review by Development Team
SugarCamp Europe 2009
start of GSoC
current code examined and understood; API, on-disk format and UI design chosen
data store enhanced to be able to deal with versions (basic API)
added (working) prev/next buttons to Journal details view
added support for importing from existing data store
added unit tests (and potentially regression tests), fixed all known bugs, submitted for review by Design Team
GSoC midterm evaluation ("working and 90% done"); added indexing (e.g. using sqlite)
code integrated upstream for increased exposure (testing!); started discussion on extended UI design (version tree etc.)
end of (university) term
end of GSoC
Fedora 12 release; Sugar 0.86 release short time later?



SugarCamp was great! I got to know a lot of the SugarLabs people - they're a cool bunch. :)

Time in general was too short to do anything more than getting to know each other, but Tomeu quickly showed me an old effort at introducing version support into data store that I didn't know about (both data store and Journal). It looks quite interesting API-wise (simply adds another, optional parameter called vid that can be used to request a specific version). Also had some time with Bernie and he offered to set up a host for VMs (for our build bots).

Unfortunately we also catched some virus in Paris, so I had to lay in bed for the next two weeks.


Slowly getting up to speed again, diving a bit into data store code (both old and new) while fixing the build infrastructure (about the same time as we ran SugarCamp Gnome did some largish changes in jhbuild that broke our sugar-jhbuild).

Discussed some possible data store API changes with alsroot, but they didn't really interfere with my design and we decided to discuss them again after the version support is finished.

Tomeu had the idea of treating the current object_id (distinguishing between instances of an activity) as a combined instance and version identifier and introducing a new "super_object_id" that does what object_id does now. The advantage would be that activities could transparently access old versions. If we'd introduce a version_id in parallel to object_id (the naive approach taken by the old implementation) an activity (or at least the framework) would need to remember and pass through the resumed version_id in order to use the corresponding branch on save.