Hi, Chris! I responded to your contact form but I'm repeating the reply here for the benefit of others running into a similar issue:
I know the versioning story is a pain point and working with some ways to handle that. I can easily add a version to the database, that's a non issue and will go into the next release.
I'm working around the guidance for versioning. Right now, the best way is to have a V1 and V2 database. I've posted a user who provided some guidance there but it basically involved using namespaces for the new versions and then detecting if the old database
existed - if so, the entities are read, transferred, and updated to the new.
One thing I'm exploring is saving a table definition with the properties in a version. Right now I iterate from the type definition itself, which obviously can collide with the serialized. With a type definition, I can look for a mismatch, then drive from
the old properties on load and the new on save and make it more automatic - something I'm looking into but has been behind the drivers I've recently implemented as a priority. I believe the drivers may provide you with some more flexibility, not sure if you've
seen the latest change set but basically the storage is completely separated from the serialization, so you can have an in-memory driver, a iso driver, an elevated trust, and I have a project I'm working on where they are looking at an Azure object storage
driver which is why I made the change in the first place.
To solve the version issue, you can have a database that uses the driver. When version two comes out, you replace the driver with a conversion driver and have a new driver for the new database. The conversion driver checks for the existence, then works with
the new driver to load (old driver) then save (new driver) and migrate the database.
To blow the database away, there is an IsolatedStorageHelper static method now for purging that you pass the root to and it recursively deletes the items on disk. You can see that in the unit tests.
Let me summarize what I think I can do to help you out, and you let me know and correct my list as needed:
1. Provide a database version - is this for your database, or for the Sterling database? The intent for user databases was to allow the version to be embedded in the database name, i.e. "Database V1" "Database V2." This discussion shows you one way a user
dealt with the versioning, but I also believe the new driver architecture will give you even more flexibility:
2. Give you access to register the table. I have to work with this because I use ordinals to store the tables internally, which is why order does matter .. I may just switch to use the full name for the table type and then there won't be a collision, but giving
you the ability to late-bind a table definition.
Will those 2 get you closer to what you need?