Question:
What are common architecture patterns/strategies of updating user data (think of XML/Json/sqlite/custom binary format) when the format of the data needs to be changed, and when that change would make reading old data (that is already stored on user’s machine) invalid?
Are there such patterns and how they are called (so I can research more about them)?
A simple example would be a config stored on the user device as a json
{
"records: [
"my_data1",
"my_data2"
]
}
With another version some details for the records need to be added, so the json would look like this
{
"records: [
{ "tags": ["tag1"], "data": "my_data1" }
{ "tags": [], "data": "my_data2" }
]
}
For all the apps I developed I use the same strategy:
- store a “version” field that has unique value for each format of the file
- for each version have a function that upgrades the format from the previous version to this version. The functions should be self-contained and not call any business logic code, even if it forces to violate DRY. Functions are stored in a list sorted by version (with the version itself)
- When loading the file, and before passing it to the rest of the app, the version of the file is searched from the latest to the oldest in the list, and all the functions applied from the next version to the last
This worked well for me so far on sqlite databases, jsons, and custom binary formats. It allowed the rest of the code never have any branching on versions and always assume the code is working with the latest version.
However, this design was made through trials and errors, I can’t find any articles of how other people handle user data versioning, not sure even how it’s called, and don’t know whether there are better ways of doing this and what I may be missing out on.
GameRaccoon is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.