views:

135

answers:

2

For those of you familiar with the Microsoft Sync Framework, this question is for you. It's regarding application versioning. Let's say that I release version 1.0 of my software and a local database sdf file is created from the version 1.0 web service, and life goes on for a while, and the user uses the application and puts data in the local database and all that, well then version 2.0 of my software comes out, and their are changes to the database (schema), such as new columns, new tables, null-ability changes, etc...

How does that work, what if the user has data in the version 1.0 database and I have published a new 2.0 web service because version 2.0 of the software is release and the version 1.0 database no longer is able to sync with the 2.0 web service, how do I get their data out of the version 1.0 database? More to the point, how to I cleanly update everyone to version 2.0 without losing any of their 1.0 data?

A: 

You can't tear down v1. web service (http://example.com/sync/v1.0/). All your v1 clients continue to sync with the v1 web service. Clients upgrade to v2. sdf by means of running deployment scripts that upgrade the database to v2. during install process (CREATE, ALTER, DROP statements). After upgrade, the clients sync to v2 service (http://example.com/sync/v2.0/).

After all clients are confirmed to upgrade to v2, you can tear down v1. webs ervice. If the number of clients is unknown, you have to rely on business decission for how long do you keep v1. up. Is not uncommon to have services running 2-3 versions in parallel to support old clients.

Remus Rusanu
That makes sense, except, wouldn't that mean that I would have to have different versions of the servers database. Because version 1 and version 2 services would both be feeding from the same server database. How do I handle the translation? I know it depends on what changes are made, but lets assume that it's a huge change.
Dylan Vester
If the ISA part of the sync service cannot reconcile, the you're going to bite the bullet and support two distinct databases and have some means to communicate between them (eg. replication). Unfortunately, in distributed systems, all schema dependencies (and Sync Framework introduces one, just like replication btw) have this inherent problem at v+ roll out, simply because you can't upgrade all participants simulatneously, and usually not even within an acceptable time window. Upgrades are one of the biggest chanllenges in any distributed app.
Remus Rusanu
A: 

In our project, which is using sync framework over WCF, we support different data versions. In our case we uses different syncServerProviders depending on which data version the client uses. If there is a change to the database schema you can configure your sync provider by writing em manually to only select/update the columns that are supported by the clients data version.

nj