I've had a few questions around this so I wanted to clarify. I apologize in advance for the confusion.
It is the goal of the Sterling team to keep the releases as backwards compatible as possible moving forward. However, as we work on various releases and changes it is unlikely we'll build the appropriate built-in migration tools until after the current release
has stabilizied. The current "driver model" with "is dirty" is likely to be released as a 1.5 version and the pending changes are related to automatically upgrading the old back up format and auto-migrating the type master for backwards
compatibility with your existing databases.
Having said that, none of the non-release change sets are considered production-ready. Treat them as alpha code. About the only specific criteria for an iterim change set is that all unit tests have passed green - and sometimes even known issues will be
checked in. Please read the change set comment and I'll work on making sure changes are posted to the discussions as well for further clarification.
For the current release, there are some caveats to help you deal with the change set if you want to start experimenting with the latest features and see how it responds in your application. I know some of you are experiencing a defect that was in the 1.0
release that is fixed in the current version so it's a requirement that you either are able to use the current change set or that you have a patch for 1.0.
The 1.0 release of Sterling kept a global type master file, the file that maps types to integers to reduce size on disk when dealing with complex entities. The problem with a master type master is you lose the ability to have autonomous databases because
they all depend on the type master for the global engine. The latest release defaults to an in-memory driver. You need to explicitly pass in the isolated storage driver to get the same functionality. If you are using the isolated storage driver,
it now saves the types locally to the database. The naming convention for the database has also changed in that it uses a hash code instead of a sequenced integer.
The manual fix for now is to let Sterling create the new database, then move the type master from the root of Sterling to the specific database. Then the driver will be accessing the same type master used to save the tables and you should be fine. I will
have this happen automatically when the release is formal, I just haven't written the feature yet. So again:
1. Create the table definitions
2. Move the type master from the root Sterling to the database-specific directory
This should resolve the issue some people are having with the loading of complex objects (i.e. ones that have nested classes). Obviously this is a work in progress so some of these may be actual defects in the current code base that the team will try to
address as quickly as possible. The team is aware of the issues with backup/restore and migration from previous versions and that is a priority to move closer to a 1.5 release.