Version support for datastore/Progress: Difference between revisions

Line 37:

== Progress ==

=== 2009-05-16 ===

[[Marketing Team/Events/MiniCamp Paris 2009|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

[http://git.sugarlabs.org/projects/sugar-datastore/repos/mainline/logs/version_prototype data store]

and

[http://dev.laptop.org/git/journal-activity/commit/?id=85ecee9bc094cd0f8f1bb7d7874ba7c7788eaafd Journal]).

It looks quite interesting API-wise (simply adds another,

optional parameter called <code>vid</code> 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 [http://buildbot.sugarlabs.org/ build bots]).

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

two weeks.

=== 2009-06-01 ===

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 [http://live.gnome.org/Jhbuild jhbuild] that broke our

[[Development Team/Jhbuild|sugar-jhbuild]]).

Discussed some possible data store API changes with [[User:alsroot|alsroot]], but they

didn't really interfere with my design and we decided to discuss them again after the

version support is finished.

[[User:tomeu|Tomeu]] had the idea of treating the current <code>object_id</code>

(distinguishing between instances of an activity) as a combined instance and version

identifier and introducing a new

"<code>super_object_id</code>" that does what <code>object_id</code> does now. The

advantage would be that activities could transparently access old versions. If we'd

introduce a <code>version_id</code> in parallel to <code>object_id</code> (the naive

approach taken by the old implementation) an activity (or at least the framework)

would need to remember and pass through the resumed <code>version_id</code> in order

to use the corresponding branch on save.

@@ Line 37: / Line 37: @@
 == Progress ==
+=== 2009-05-16 ===
+[[Marketing Team/Events/MiniCamp Paris 2009|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
+[http://git.sugarlabs.org/projects/sugar-datastore/repos/mainline/logs/version_prototype data store]
+and
+[http://dev.laptop.org/git/journal-activity/commit/?id=85ecee9bc094cd0f8f1bb7d7874ba7c7788eaafd Journal]).
+It looks quite interesting API-wise (simply adds another,
+optional parameter called <code>vid</code> 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 [http://buildbot.sugarlabs.org/ build bots]).
+Unfortunately we also catched some virus in Paris, so I had to lay in bed for the next
+two weeks.
+=== 2009-06-01 ===
+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 [http://live.gnome.org/Jhbuild jhbuild] that broke our
+[[Development Team/Jhbuild|sugar-jhbuild]]).
+Discussed some possible data store API changes with [[User:alsroot|alsroot]], but they
+didn't really interfere with my design and we decided to discuss them again after the
+version support is finished.
+[[User:tomeu|Tomeu]] had the idea of treating the current <code>object_id</code>
+(distinguishing between instances of an activity) as a combined instance and version
+identifier and introducing a new
+"<code>super_object_id</code>" that does what <code>object_id</code> does now. The
+advantage would be that activities could transparently access old versions. If we'd
+introduce a <code>version_id</code> in parallel to <code>object_id</code> (the naive
+approach taken by the old implementation) an activity (or at least the framework)
+would need to remember and pass through the resumed <code>version_id</code> in order
+to use the corresponding branch on save.