Migration Issues

Sep 10, 2010 at 12:31 AM

Hello,

I'm currently investigating into client side databases for silverlight.
Sterling OODB seems to be a good candidate for my needs. But
there is still one issue I'd like to discuss.

Suppose we have a silverlight application using the sterling-db to store
master data retrieved from a web service. The application would offer
an in-built mechanism to keep the data up to date.
This application would be running both inside a browser (online)
and in out-of-browser mode (potentially offline). Now I would like
know how to deal with changes to the data model, i.e. a new property
in a class that is already stored in the client side database?

An obvious solution would be to put new properties in a new class
referencing the class they actually belong to. But maybe that's not
even necessary!?

I'd like to hear your thoughts on the matter.

 

Regards,

Stefan

Coordinator
Oct 28, 2010 at 2:54 AM

Good points there. Right now that is the way to do it - to wrap in a new class. I'm looking into that now, because Sterling rolls its own serialization it is not like the base BinaryFormatter that deals gracefully with new properties - Sterling expects a particular order.

This is one of the reasons I did multiple databases. You can see if there is an older database version, and migrate to the newer - use a class with the old vs. new signature and migrate that way.

I will look into a better approach moving forward.

Oct 28, 2010 at 10:42 AM

First of all: thanks for your reply!

I have also considered the option of creating a new database for every new version of the client (if the data model changes).
I haven't tested it yet but it seems to be manageable - a bit quirky though.
Migration would then be roughly working like this:

  1. The name of the database is derived from the client-version (i.e. 'MyDB-1.0.0', 'MyDB-1.0.1', ...)
  2. Whenever we start working on a new version all classes of the data model are copied to a new namespace (e.g. 'V100' -> 'V100.Products', 'V100.Customers', ...),
    all changes are made to classes the application actually is using (in whatever namespace we have designated them to be).
  3. Same goes for the database class itself ('V100.MyDatabase').
  4. In order to move from a previous database version to the current a handler is called depending on the db version we
    are migrating from (e.g. 1.0.0 -> 1.2.0; 1.1.0 -> 1.2.0; ... ). The handler copies(convert, fill in defaults, etc) all data from one database to
    another.
  5. Eventually myDatabase-[OldVersion].Purge(); is called.

Anything to add?

 

Greetings,

Stefan