Mindscape Blog » Blog Archive » Inheritance and database synchronisation

Inheritance and database synchronisation

One of the big time-saving features in the LightSpeed designer is the ability to synchronise your database and your LightSpeed model — either by updating your model to reflect changes to your database or vice versa. It’s such a big time-saver that when people run into its limitations they feel quite disappointed. Until now there have been two major limitations on schema round-tripping: it doesn’t handle value objects, and it doesn’t handle inheritance. The reason for these limitations is that they break the easy mapping of entities to tables and properties to columns: value objects add extra columns to a table, and inheritance not only adds columns but changes the naive entity-to-table mapping. Of these two limitations, inheritance has been the one that most people run into.

We’re therefore pleased to announce that we’ve now added experimental support for inheritance to the synchronisation engine.

Synchronisation is now supported both for single-table inheritance scenarios, where all columns from across the hierarchy are collected into a single database table:

and for “concrete” table inheritance, where each non-abstract entity has its own database table which includes columns for both local and inherited properties:

(For more information about the two kinds of inheritance, see Inheritance in LightSpeed.)

Synchronisation still has a couple of minor limitations. Some of these are because of the fact that the database just doesn’t know about inheritance. For example, if you’re using single-table inheritance, and you’ve added a column in the database which is meaningful only on a derived type, we can’t know about that, so we’ll offer to add it to the base class. We hope at some point to add a “move to derived entity” command which will address this and will also with the initial creation of STI hierarchies from a database. Others are just due to resource limitations. For example, if you’re using concrete table inheritance, we still don’t handle concrete base classes, because of the complexity of reconciling database changes up and down the hierarchy — but the designer now supports marking base classes as abstract, which we expect to be the more common case anyway.

Been waiting for this since 2.0? Grab the latest nightly and take it for a whirl!