Places:Plan: Difference between revisions

Jump to navigation Jump to search

Places:Plan (view source)

Revision as of 19:26, 10 September 2009

54 bytes removed ,  10 September 2009
→‎Places downgrades should allow any schema change
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, ...)
The idea is to backup history when a downgrade is about to start, create a new database, then restore bookmarks and history. This would just require us to upgrade historyvisits table in a compatible way, leaving anything other freeform (what about page annotations then?).<br/>
Initial idea was to backup history, guaranteing some column to persist.
Why not backing up history periodically with bookmarks? Just for privacy reasons.<br/>
 
This would just require to split out backup&restore functionality to a separate backupRestore component (actually they are in PlacesUtils) so we can call them from history service.<br/>
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.
So on downgrade we would just throw away the db and force a restore from json format that should be guaranteed to stay unchanged.<br>
Instead the changes will be described in diff structures, that we can store in a schema_diffs table. the diff would be a JSON string with properties to describe the change, or pre-built SQL queries.
What about inputhistory? Are there other history data we actually don't backup?<br/>
On init the service will read the schema version, if it differs it will pass the connection to the migration component. This should in some case export data, rebuild schema, and reimport data. other additive cases could be simpler.
This would be already needed for at least livemarks and tags changes.<br/>
Since all schema steps are self contained in the database, the migrator can walk through them regardless application version.
Could we just accept that if a user is downgrading he will lose history and relnote the thing? probably not.
 
NOTE: This should be a Storage Component, so that anyone can use it to migrate his SQLite database.


*'''PROS:''' no downgrade restrictions for schema
*'''PROS:''' no downgrade restrictions for schema
*'''CONS:''' have to backup history, some table must be guaranteed to be additive (moz_historyvisits, moz_annos, moz_annos, moz_anno_attributes).
*'''CONS:''' have to design and implement the migration component in an abstract enough fashion to handle many cases.
*'''EST:''' 2 weeks.
*'''EST:'''
*'''BUG:'''
*'''BUG:'''
*'''DEPENDS:'''
*'''DEPENDS:'''
Mak77
Confirmed users
595

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/167731"

Navigation menu