Last night I landed Bug 1224440, which alters how BrowserTable and BrowserDB do upgrades.
Previously, our tables were expected to know how to create themselves at any version, and upgrade themselves to any version. In reality, this probably didn't work, and it's a pretty unpleasant way to ship database code. Now they're expected to upgrade to and create at the current version only. The burden now lies on test code to create older versions of the table to correctly test upgrades. When you alter a database schema — typically when you find yourself changing BrowserTable.DefaultVersion — you must now do the following: - Add to TestSQLiteHistory a historical implementation of the soon-to-be-obsolete BrowserTable. Verify that it creates the same database schema as a clean launch of master. This is our snapshot of code we used to ship. - Add to testUpgrades the boilerplate to verify updates from that version to your new current schema. Extra points if you add data to be upgraded and test that the right thing happens! Note that in this case it's a *bad thing* to have tight dependencies on current code — we explicitly want to avoid altering the behavior of these snapshots by making changes to mainline code. Code duplication is, for once, welcome. (Why ship code? Why not ship .sqlite files created by our old versions? Let's do that too. Patches welcome.) Let me know if you have any questions. -R
_______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
