Notes for Changset

Mar 16, 2011 at 12:44 AM

I just checked in a major refactoring of Sterling: Changeset 74664

This will break the phone build for now. The next check-in will have this fixed.

I totally refactored the Sterling engine to remove the intrinsic dependency on the isolated storage system. This was strewn through-out and prevented some changes such as non-Silverlight .NET versions from being created.

The core engine is now truly just a serialization engine. It uses a driver to manage persistence, and the default, built-in driver is an in-memory driver. You can run the "main" unit tests to see how fast this is.

The isolated storage engine now exists as a separate driver. This driver supports all of the old, but the code has been somewhat optimized. The save operation now temporarily caches the object while saving. If a load on another thread attempts to access it, it will immediately grab the cached object and not block. Both will lock on a mutex for other updates, however, so race conditions are avoided and you are always guaranteed the latest snapshot (because if a save was in place and new save initiated, it won't actually execute until the first is finished).

I also provided the ability to choose site-wide or application-wide scope on the driver.

This breaks compatibility in a small way, but don't worry - as of now it should be 100% backwards compatible with 1.0 using a helper method I'll create. I'm storing a version in the database backups now so they can be smarter moving forward. If you've already taken backups, I'll provide a converter to convert 1.0 backups to Sterling vNext. More importantly, the location of the type master file has moved into the database so the backup is now self-contained. I'll also include code in the isolated storage driver to detect if the type master is in the local database, and if not, move a "master copy" over.

There is no more tables.dat file as the engine can determine ordinality based on how you register the tables. There is no more databases.dat because instead of maintaining and serializing/flushing an index of those, I'm just using the hash code for the isolated storage path.

Please feel free to pull this down and kick the tires and let me know your thoughts. As always this isn't even an alpha, it's a change set drop so I'm just informing - thorough testing has not yet been done.

In addition, however, I will be releasing a driver to elevated trust (local file system) and a driver for disk (.NET, non-Silverlight).

Because drivers are per database, you can now create a "cache" database for transient objects in memory and use the isolated storage for persisted items. I will also provide guidance eventually on creating a driver that aggregates the isolated storage driver but also keeps a journal for roll backs/commits and even sends updates to the server via a web service - with the new driver architecture, sky is the limit and my hope is the community will find the model flexible enough to provide their own drivers for various situations as well.