Is using partial classes for supporting multiple versions of data entities for continuous delivery scenarios a bad idea?

Question

When you want to have continuous delivery any data schemas that you have must support multiple versions of your application at the same time (as you may have multiple version deployed when new versions are rolling out)

In my specific case I have entities stored in Azure table storage. When I am making changes to my entities I am usually having to add properties (as removing or renaming them is a bad idea as old versions of the application will potentially break), but once a new version is completely rolled out I don't need the old versions properties anymore as all the servers out there are using the new version, which means in the next rollout I can remove some of the old properties.

I'm wondering if this problem can be solved more easily by having partial classes for each version of the entity. This ensures that one version will always be accumulative for a previous version (ie will never take anything away or change anything) but will allow delegation to an existing property if something just needs to be renamed.

Once a version has been completely rolled out and the old version will never be needed then the partial classes could be consolidated into a single class again (and any unneeded properties removed). If you know that you are only going to have a couple of versions 'live' at anyone time then you could perhaps use a 'current' version and a 'vNext' version explicitly.

I've not tried this as a solution yet but wondered if anyone else has tried an approach like this and has any feedback, or if anyone has thoughts on whether this is a good or bad idea?

Answer 1

Partial classes are just a means of splitting one class into multiple files. It is particularly useful when parts of a class can be generated but you want custom code in it as well. I don't see how this helps you select which properties are obsolete for a new version or not.

I would suggest attributing obsoleted properties with [Obsolete("since version ...")] to track which properties you can remove at a later time.

You may have use for separating old and new api's with different entities, and those may benefit from inheritance, to clearly specify which properties didn't even exist in the older api.

Answer 2

I don't like the idea of partial classes, your solution will become a Tomb.

If you are using SQL, you can use SSDT (SQL Server Data Tools) And you will have ability to run pre-script or post-script while deploying, read current server version and depends on this version alter, update, delete ... And then update version after script finished successfully.