Difference between revisions of "Version support for datastore/Results"
Sascha silbe (talk | contribs) (write up final report) |
(format for transclusion) |
||
| Line 1: | Line 1: | ||
| − | == | + | === Version support for Datastore === |
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. | 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 === | + | ====VCS benchmark ==== |
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. | 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. | ||
| − | === Datastore redesign proposal === | + | ==== Datastore redesign proposal ==== |
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). | 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). | ||
| − | === Prototype === | + | ==== Prototype ==== |
[[Image:journal-version-mockup-2.png|800px|thumb|left|Journal details view with version support]] | [[Image:journal-version-mockup-2.png|800px|thumb|left|Journal details view with version support]] | ||
| Line 17: | Line 17: | ||
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). | 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). | ||
| − | === Prefix search support === | + | ==== Prefix search support ==== |
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". | 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". | ||
| − | === Test suite === | + | ==== Test suite ==== |
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. | 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. | ||
| − | === Minor bug fixes === | + | ==== Minor bug fixes ==== |
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] | 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] | ||
| − | === Minor enhancements === | + | ==== Minor enhancements ==== |
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. | 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. | ||
| Line 35: | Line 35: | ||
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. | 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. | ||
| − | === Style fixes === | + | ==== Style fixes ==== |
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]]. | 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]]. | ||
Latest revision as of 12:41, 11 September 2009
Version support for Datastore
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.