Currently when there is a breaking change to the database, our upgrade procedure is to delete the database and start fresh. As ANMS collects more users, this will not be an acceptable option for users when upgrading releases.
Following the ANMS 2.0 release I recommend that we:
- Track any Database Schema changes made
- Maintain a discrete SQL file (ie: anms_2.0.0_to_2.0.1_upgrade.sql) containing the necessary SQL ALTER statements to update existing tables, rather than starting fresh.
- On subsequent point releases, we test and provide instructions for users to apply any necessary updates to their existing DB if they wish to preserve their existing data.
Currently when there is a breaking change to the database, our upgrade procedure is to delete the database and start fresh. As ANMS collects more users, this will not be an acceptable option for users when upgrading releases.
Following the ANMS 2.0 release I recommend that we: