Important: Changest 76015

Apr 10, 2011 at 7:09 PM

This topic is related to change set 76015:

This can be considered the "alpha" for version 1.5. A 1.4 beta will be released shortly once the decision regarding a desktop version has been made (most likely it will happen this release but still going through some nuances with using the file system directly vs. isolated storage which is also available there).

If you were using any post-1.0 builds, this build will likely break your installed databases. The issue is with saving indexes. In 1.0, the indexes were saved as index value(s), then key. In the interim 1.x builds, this was reversed in the isolated storage drivers making it incompatible. This changeset fixes it for 1.0 compatibility but of course will break the interim files. I do not have the bandwidth to support interim changesets as our focus will be on parity between the official releases, but feel free to contact me if it's an issue. The fix is not that hard, you simply need to read in the index using the old method and then write it back out using the new method before activating the database.

The current release includes the IsDirty predicate for conditioning whether Sterling will save an object or not (this is currently only available for registered types, i.e. the classes that have table definitions), and the various drivers.

Because you may want to deploy Sterling as an elevated-trust only solution or maybe as just an in memory cache, the default version uses the in-memory cache because this has no other dependencies. For backward compatibility with isolated storage, you'll need to reference the isolated storage driver and then send it into the database definition, like this:

RegisterDatabase<MyDatabase>(new IsolatedStorageDriver());

That is also how you would create an elevated trust database.

The isolated storage driver can take parameters now. The desktop and phone versions can take a different base path if for some reason you don't like Sterling. This has not been thoroughly tested. The browser (non-phone) version also supports using a site-scoped database (as opposed to application-scoped) so applications in the same domain may share the same databases. Again, this has not been heavily tested - all of the backwards-compatible features have been.

Finally, upgrading from 1.0 is opt-in because many will be using 1.5 as their "starting" point. To upgrade from 1.0, here are the steps:

1. Include a reference to the appropriate IsolatedStorageUpgrade DLL (regular or phone-specific)

2. BEFORE you activate the engine or register the database, make a call to the static Upgrade.DoUpgrade and pass a delegate to handle when the upgrade is finished.

3. When it is done, then you can activate and you will be converted.

There is no progress reporting because it's not a practical metric at this point in time. If you have multiple databases, ALL databases will be updated. Keep in mind this will only work if your signature is the same. You cannot both update from 1.0 to 1.5 AND change the structure of your database in the same step. We are still working on the "story" for updating existing classes and that will be a major factor in the 2.0 release, is being able to seamlessly update your classes moving forward.

The upgrade process spawns a background worker. It allows for rollback. You can call a cancel method to abort, and on the phone if the user tombstones or swaps before it is done, it will just start over and keep trying until successful. Once it is successful, it will purge the old database and future calls will result in an immediate callback. The result is that the first time it is run there is a slight pause as it upgrades the files for you, but subsequent calls are just as fast as if you were running it all of the time.

Here is an example that used to activate the engine in the "activateengine" method, but is now using the upgrade call. This is called ALL the time but again only really does something the first time, any other time it just jumps immediately to the "engineready" code.

As always, thanks for all of your feedback and support. Those of you taking the time to work with the early bits provide valuable feedback and help make it a better product for everyone, so thanks! We'll get the beta out shortly and then let that spin for awhile with nothing but bug fixes to ensure a stable 1.5 release.

Last note before the sample code ... right now I'm not sure we'll have an auto-conversion for the old-style backups because they simply don't contain the right data which is why the format was changed. The appropriate pattern will likely be restore BEFORE you upgrade, and then the upgrade should work fine.

Thanks again!

private void _ActivateEngine()

private void _EngineReady()
    _engine = new SterlingEngine();
    _logger = new SterlingDefaultLogger(SterlingLogLevel.Verbose);
    _database = _engine.SterlingDatabase.RegisterDatabase<MyDatabase>(new IsolatedStorageDriver());
Apr 18, 2011 at 2:00 PM

Hi Jeremy,

I'm working on v2 of a published Windows Phone 7 application that was based on an almost v1 version of Sterling so I'm using the above code to debug/test the upgrade process. Unfortunately, when I hit F5 in Visual Studio it thinks it's significantly different from the previous version and uninstalls/reinstalls so I never get into the upgrade scenario. Any tips on how I can debug the upgrade process?


May 2, 2011 at 6:15 PM


I'm checking out the 1.4 beta, using the Server dll. One remark I have right now is to sign the assemblies with a strong key. I haven't been able to test it any further as I can't build my signed assembly with a reference to Wintellect.Sterling.Server.dll which isn't signed.


Jul 20, 2011 at 3:01 AM

Hi Jeremy,

Currenlty I am using 1.1.4119.32103 version of Wintellect.Sterling.WindowsPhone.dll. I am trying to upgrade to 1.5 version dlls.

But I am getting InvalidCastException when I use 1.5 version dlls.

Please help me on this issue.