Best practices for database backward compatibility

Question

I am working on an app which has multiple versions deployed in the market. Different versions have modified databases and databases are to be synced between local storage and server storage by signed users. The problem is a user can have different versions of the app installed in different device and might want to keep database synced. Now due to different database versions (different schemes, i.e. altered columns or data types) its hard to get synced for same account. I wonder if there is any well known pattern to resolve this kind of issues. I believe this is a very common problem and must have some better approach to handle.

So far i am thinking to make a wrapper to convert one db version compliant data (received from server) to another db version compliant data (saved to local storage).

Edit: In response to @RobertHarveys comment, lets assume each database version has different scheme. For example new colums may be added in one version and old colum may be removed in later version. Moreover data type can be changed in other versions.

Answer 1

Current Scenario:

DEVICE1:

• col1
• col2
• col3

DEVICE2:

• col1
• col2
• col4
• col5

DEVICE3:

• col1
• col3
• col5

And each device is connected to your "server", i.e. there is a copy of the data on your side.

Syncing:

In order to synchronize in a meaningful way, the server component has to have a superset of all columns

SERVER:

• col1

• col2

• col3

• col4

• col5

Each device queries for a current representation of the server's state and update it's columns (e.g. Device2 picks 1,2,4,5) accordingly.

This should do the trick.

---

Edit for answering questions from the comment section

what would be if the data type (of a column) is changed in one version?

Depends on what you mean by datatype is changed? Say, you have in V1 chosen String for DOB and in all other versions, you have a Timestamp there should be no problem: the update has to deal with a marshalled form and the process of unmarshalling should do the necessary conversions (writing a string into the DB or converting a string to a Timestamp).

In general: There should be one canonical form ("the truth") on the server and each application should do the transposition to their needs.

Also how do we deal with the naming for the columns (for example, Person (name, age, dob)) ? Do you think I should name like Person('name_v1, age_v1, dob_v1'), Person('name_v2, height_v2, age_v2, dob_v2') etc. something like that?

From what was written above should be clear: There is no need for special naming of different column_versions. Problematic: if you have some kind of length restrictions: the shortest one wins.

---

From what I read so far, I would recommend, seeing this only as a temporary solution and strongly recommend to motivate (via money, features, money&features, whatever) people to upgrade to a newer version of your application. You and your customer will have less headaches.

Answer 2

In such cases, you need to keep track of users with app version. Whenever you are making any changes in database schema, if any of the user is using previous version, don't delete the column name. You can do only when there is no any user using that version.

For managing multiple App version, you need to work more on APIs. You can handle such cases by using version number at API level.

While using API, send version number in API and give/get the response according to the version changes.

Answer 3

Application should be planned from the start for backward compatibility, so any new version shall not remove old feature (or remove columns the DB schema). This way you guarantee new version will always work with old DB.

But if you need only sync certain data, you may add synchronization adapter for every version to unify data exchange between them without changing the version internals a lot and keeping DB versions more independent and flexible.

Answer 4

We use three levels of own version numbering.

1. Frontend code version (hardcoded)
2. API version (hardcoded)
3. Database version (stored in a db constant)

If they not all are equal version, force some update of the deviant level. The check and update routine is triggered at startup.