Difference between revisions of "Version support for datastore/Results"
Sascha silbe (talk | contribs) (write up final report) |
(No difference)
|
Revision as of 13:17, 24 August 2009
Results
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.
VCS benchmark
My VCS benchmark that was geared towards the data store use case 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.
Datastore redesign proposal
The 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 uid for the object identifier) has historically grown and isn't well-defined in some aspects. My 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).
Prototype
The 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).
Prefix search support
As a test balloon for the code review process I added support for doing 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".
Test suite
The 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.
Minor bug fixes
Several pre-existing bugs have been discovered and fixed in all of sugar-toolkit, sugar-datastore and sugar: #1040, #1024, #1053, #1059
Minor enhancements
A trace decorator has been added in order to ease debugging. It helped a lot during version support development. Not having the 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 (#1198+#1201) and sugar-toolkit (#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 add a technical details view (file size, MIME type, creation date) to the Journal details view.
Style fixes
The 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 (#1108, #1109). Also letting the logging code do the formatting of the log message (#1210, #1211, #1213) has been added to the style guide.