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
I'd like to hear your thoughts on the matter.
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
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.
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:
- The name of the database is derived from the client-version (i.e. 'MyDB-1.0.0', 'MyDB-1.0.1', ...)
- 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).
- Same goes for the database class itself ('V100.MyDatabase').
- 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
- Eventually myDatabase-[OldVersion].Purge(); is called.
Anything to add?