Confirmed users
595
edits
| Line 181: | Line 181: | ||
When we change schema we have to ensure tables are compatible with previous version, this is blocking us from doing big/important changes to how we store our dataset. | When we change schema we have to ensure tables are compatible with previous version, this is blocking us from doing big/important changes to how we store our dataset. | ||
We should create a new downgrade path able to manage any kind of schema change and backport it to any supported version (3.6, 3.5, 3.0, ...) | We should create a new downgrade path able to manage any kind of schema change and backport it to any supported version (3.6, 3.5, 3.0, ...) | ||
Initial idea was to backup history, | Initial idea was to backup and restore history reuilding the db, but this has disadvantages across app versions. | ||
Better and newer idea is to use a migration component similar to the migration components in Rails and Django. The component will be ported to all supported versions and will stay frozen on schema changes. | Better and newer idea is to use a migration component similar to the migration components in Rails and Django. The component will be ported to all supported versions and will stay frozen on schema changes. | ||
| Line 188: | Line 188: | ||
Since all schema steps are self contained in the database, the migrator can walk through them regardless application version. | Since all schema steps are self contained in the database, the migrator can walk through them regardless application version. | ||
NOTE: This should be a Storage Component, so that anyone can use it to migrate his SQLite database. | NOTE: This should be a Storage Component, so that anyone can use it to migrate his SQLite database. Or maybe transparent, so that if i open a database connection setting a magic optional param, the schema will be automatically upgraded/downgrade. | ||
*'''PROS:''' no downgrade restrictions for schema | *'''PROS:''' no downgrade restrictions for schema | ||