Places:Migration: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 33: Line 33:
|}
|}


A general blurb for handling schema changes for bookmarks:
*** DRAFT *** DRAFT *** DRAFT ***


We'll backup bookmarks info places.sqlite into bookmarks.html on quit, so that on schema change we don't have dataloss, but we also archive (like fx 2).  as a side benefit, if you go back from fx 3 to fx 2, you'd get any new bookmarks.  (but if you went forward again to fx 3, we would not reimport new fx 2 bookmarks, as that only happens on a schema change, as we are proposing.  but the user could import manually.  also, we need to fix the export code to cover microsummaries and livemarks, which the fx 3 places export code might not be doing.  as far as exporting other data (to avoid a lossy transition from schema x to schema y, we might write out attributes in bookmarks.html, but we need to make sure fx 2 and other  browser can handle that gracefully.)
Notes on handling schema changes for bookmarks:


note, we don't want to dump/import on every schema change. only if necessary, as some (inevitable) schema changes can be done with migration code
* Bookmarks from places.sqlite will be backed up to bookmarks.html at shutdown.
* For the upgrade from Places-no-bookmarks to Places-bookmarks, we'll delete and re-initialize the bookmarks tables.
* For subsequent schema changes we'll write migration code.
* Since SQLite doesn't allow column drops, those changes will require staging the data in a temporary table, dropping the old table, and then renaming the new table.
* The dump approach can be lossy, so it's key that we evaluate the necessity of this and fix any data-loss moving forward.
* Bookmarks.html is archived to the {profile dir}/bookmarkbackups directory (like Fx2).
* If you downgrade from Fx3 to Fx2, you'd get any new bookmarks, as Fx2 will use the boomkarks.html file.
* If you then upgrade again to Fx3, new Fx2 bookmarks are not automatically re-imported, as that only happens on a schema change. The user can import manually.
* The export code needs to export and import microsummaries and livemarks, which
* As far as exporting other data to avoid a lossy transition from schema x to schema y, we might write out attributes in bookmarks.html, but we need to make sure Fx2 and other  browser can handle that gracefully.
* We don't want to dump/import on every schema change. Only if necessary, as some (inevitable) schema changes can be done with migration code.
 
Bugs:
* {{bug|374876}} - write out bookmarks.html on close
* {{bug|374640}} - upgrade from 3a* -> 3a3 breaks stuff
* {{bug|373239}} - add schema versioning

Revision as of 16:27, 23 March 2007

Places Migration Scenarios

Need to detail the up/down/sidegrade scenarios for Places, how they're handled.

Upgrades:

from to action notes
<=2.* 3.0a2 history moves to Places
3.0a2 3.0a3 some schema changes XXX bug#s
<=2.* 3.0a4 history and bookmarks move to Places
3.0a2 3.0a4 bookmarks move to Places
      • DRAFT *** DRAFT *** DRAFT ***

Notes on handling schema changes for bookmarks:

  • Bookmarks from places.sqlite will be backed up to bookmarks.html at shutdown.
  • For the upgrade from Places-no-bookmarks to Places-bookmarks, we'll delete and re-initialize the bookmarks tables.
  • For subsequent schema changes we'll write migration code.
  • Since SQLite doesn't allow column drops, those changes will require staging the data in a temporary table, dropping the old table, and then renaming the new table.
  • The dump approach can be lossy, so it's key that we evaluate the necessity of this and fix any data-loss moving forward.
  • Bookmarks.html is archived to the {profile dir}/bookmarkbackups directory (like Fx2).
  • If you downgrade from Fx3 to Fx2, you'd get any new bookmarks, as Fx2 will use the boomkarks.html file.
  • If you then upgrade again to Fx3, new Fx2 bookmarks are not automatically re-imported, as that only happens on a schema change. The user can import manually.
  • The export code needs to export and import microsummaries and livemarks, which
  • As far as exporting other data to avoid a lossy transition from schema x to schema y, we might write out attributes in bookmarks.html, but we need to make sure Fx2 and other browser can handle that gracefully.
  • We don't want to dump/import on every schema change. Only if necessary, as some (inevitable) schema changes can be done with migration code.

Bugs:

Retrieved from "https://wiki.mozilla.org/index.php?title=Places:Migration&oldid=52771"