Places:Migration

From MozillaWiki
Jump to: navigation, search

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

Testing

We need an automated way of testing migrations:

  • First install, no profiles
    • Test migration from each supported browser/external-app
  • Upgrades from major versions
  • Downgrades to major versions
  • Sidegrades between locales, partner builds, other

Also, we need to detail a policy regarding support for foward/backward/ad-infinitum support for bookmarks.

      • 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: