Schema evolutions

Author: Gábor Dolla April 30th, 2013

, , ,

This feature is only available in JayData Pro version and works with local providers only.

You can download JayData Pro from jaystack.com after a simple registration. For commercial usage you can either evaluate it for 30 days for free or you can buy it. For non-commercial usage it’s free.

“Oh, look out you rock ‘n rollers. Ch-ch-ch-ch-Changes…”

Changes are inevitable. Your code is changed. Your data are changed. Your data structure is changed.

In a web application when the code is changed a simple refresh is enough. In a mobile application you have to upgrade the app. When your data structure is changed then change management on the device can be tricky.

In a simple case you add a new field or table or remove one. Piece of cake. But when you rename a field or change its type then change can not be done automagically, it requires custom logic. As JayData provides an abstract interface to the developer a generic, provider independent and customizable solution to this problem.


The idea is that in your code you only have to define your current schema only. This of course puts some burden onto us as we have to find out when the schema has changed and also we have to store the previous schema so we can still access your data stored with the previous schema. We do this by storing the schemas in a local database and when you define your current schema we calculate a hash of it so we can find out when the schema has changed. If you want to avoid unnecessary schema upgrades then do not fiddle with the schema definition. The migration must be done in a provider independent way so you can use JayData’s JSQL or ItemStore API for it. The old and the new schema must exists parallel so the name of the local database is no longer is what you specified but its name has a suffix which is its version number. When you define your schema JayData creates global types for it so that you can easily instantiate your objects. During the migration you should be able to access your old schema and your new schema and that’d cause name collision therefore we have a new feature to define a type inside a container. This type-in-a-container feature is available in the free version, too, while schema migration feature is not.

The syntax has sligthly changed but of course you can use the old syntax if you do not want to use schema evolution feature.

You can have many openDatabase call for the same database and you do not have to worry about databaseCreated ot schemaChanged events, then run only once and before any of the contexts get ready.

If you like Schema Evolutions, you might want to read more about JayData Pro and more JayData Pro modules.

, , ,