Version support for datastore/Results: Difference between revisions

Overall I think the project was a success. For various reasons it didn't quite go the way i imagined, but nevertheless got a fully working prototype I can base further development on. Many of my not directly version related patches were merged upstream for 0.86.

My [http://git.sugarlabs.org/projects/versionsupport-project/repos/mainline/trees/master/benchmarks VCS benchmark] that was geared towards the data store use case [[Version support for datastore/Progress#Benchmark_results_2|has shown]] there's no perfect match -- depending on the hardware Sugar is running on (CPU speed, IO bandwidth, storage size) different VCSs will perform best. This emphasizes the need for a modular design with runtime-selectable VCS backends in case we're going to use one at all.

The [[Development Team/Datastore Rewrite|current datastore]] codebase doesn't lend itself very well for adding VCS backend support to it; also the current API (including the names of special properties like <code>uid</code> for the object identifier) has historically grown and isn't well-defined in some aspects. My [http://git.sugarlabs.org/projects/versionsupport-project/repos/mainline/blobs/master/datastore-redesign.html proposal] (follow "raw blob data" link) shows how a future datastore implementation could work, including a new API (that's based on the old one, but with clear definitions and guarantees).

[[Image:journal-version-mockup-2.png|800px|thumb|left|Journal details view with version support]]

The [[Development Team/Datastore Rewrite|current datastore]] has been enhanced to add version support - now based on the new API defined in the proposal mentioned above. The UI side has been adjusted to that new API. To the user, it it totally unobtrusive: the text field showing the time of the last modification just got replaced with a combo box showing all existing versions (with the latest one being the default). Selecting a different version will show the details for that version and also allows the user to resume it. While the UI changes are minimal, the impact is large: even after doing any number of modifications the user can "go back" and look at or even continue working on older versions -- similar to undo / redo functionality some applications offer (though most of them can't undo anything once the application has been closed).

As a test balloon for the [[Development Team/Code Review|code review]] process I added support for doing [http://dev.sugarlabs.org/ticket/1090 full-text searches on specific properties by using prefixes] inside the query string: E.g. entering "mime_type:text/plain" in the Journal query field will only show those entries that have the "mime_type" property set to "text/plain". Previously the user could only search '''all''' properties for "text/plain".

The [http://git.sugarlabs.org/projects/sugar-datastore/repos/versionsupport/trees/onlytest2/ test suite] for sugar-datastore has been revived from an old git version and modified to test the public (=DBus) API instead of the internal ones. It already helped discovering two bugs in my prefix search support changes.

Several pre-existing bugs have been discovered and fixed in all of sugar-toolkit, sugar-datastore and sugar: [http://dev.sugarlabs.org/ticket/1040 #1040], [http://dev.sugarlabs.org/ticket/1042 #1024], [http://dev.sugarlabs.org/ticket/1053 #1053], [http://dev.sugarlabs.org/ticket/1059 #1059]

A [http://dev.sugarlabs.org/ticket/1089 trace decorator] has been added in order to ease debugging. It helped a lot during version support development. Not having the [http://dev.sugarlabs.org/ticket/1207 layoutmanager side-stepped] by several parts of the data store helped made the prototype code much cleaner. Patches to clean up quite a bit of redundancy in accessing the data store from sugar ([http://dev.sugarlabs.org/ticket/1198 #1198]+[http://dev.sugarlabs.org/ticket/1201 #1201]) and sugar-toolkit ([http://dev.sugarlabs.org/ticket/1197 #1197]) have not been accepted for 0.86.

Unrelated to my version support work, but operating on the same set of modules is a patch to [http://dev.sugarlabs.org/ticket/1215 add a technical details view] (file size, MIME type, creation date) to the Journal details view.

The [[Development Team/Code Review|code review]] process mandated some stylistic conventions that were not yet followed by some of the pre-existing code. I've submitted patches to fix that ([http://dev.sugarlabs.org/ticket/1108 #1108], [http://dev.sugarlabs.org/ticket/1109 #1109]). Also letting the logging code do the formatting of the log message ([http://dev.sugarlabs.org/ticket/1210 #1210], [http://dev.sugarlabs.org/ticket/1211 #1211], [http://dev.sugarlabs.org/ticket/1213 #1213]) has been added to the [[Development Team/Code guidelines#Miscellaneous|style guide]].