Hi folks,
Just a heads up that some big-ish changes to IndexedDB landed today on m-c.
1. The main change that affects users is bug 1112702, which switched IndexedDB
databases to be non-durable by default.
2. The the schema version for all databases has changed, so once you open a
database on trunk builds and it upgrades you will not be able to open that same
database in an aurora/beta/release build.
Details follow!
1. IndexedDB databases are now non-durable by default. This means that
"versionchange" and "readwrite" transactions will now fire "complete" events
after the transaction has committed but potentially before all data has been
written to disk. If a crash or power loss occurs at just the right moment then
the transaction will be lost/rolled back. It should still be impossible to ever
see database corruption though. This will mean faster delivery of "complete"
events, and more closely aligns with the performance vs. stability tradeoffs
other browser vendors have chosen.
The IndexedDB API does not currently have a way to say "no, really, I want to
make sure that this important data is saved to disk before I continue". Some
examples might be things like saving contacts, reservation confirmations,
one-time download tokens, etc. We will work with the spec authors to get
something in v2 of the IndexedDB specification for this.
In the meantime, if the "dom.indexedDB.experimental" pref is set (defaults to
|false| in Firefox and |true| in B2G, I think), you can specify the
"readwriteflush" transaction mode if you want to ensure that data is written to
disk before the "complete" event is delivered. E.g.:
var transaction1 = db.transaction("foo", "readwrite");
// Use transaction1...
transaction1.oncomplete = event => {
// Data may not yet be written to disk! A crash or power loss
// here could roll this transaction back.
};
// With "dom.indexedDB.experimental" set to |true|:
var transaction2 = db.transaction("foo", "readwriteflush");
// Use transaction2...
transaction2.oncomplete = event => {
// Data is guaranteed to be written to disk. A crash or power
// loss here will retain this transaction.
};
Waiting for data to be flushed to disk can take a long time, so unless the data
you're saving is critical/non-recoverable then you should probably be fine
continuing to use the "readwrite" transaction mode.
2. The database schema and journal mode have changed, and it should
dramatically decrease the size on disk of databases for desktop builds and
should increase performance of many operations due to decreased I/O. To do this
we have to rebuild the schema of the database on first load and that process
might take a little while, so be on the lookout for slowly opening databases.
Thankfully this is only required once, but thereafter these databases won't
work in an older build! Jumping back and forth between
nightly/aurora/beta/release builds will not work.
Please file any issues you see in Core:DOM::IndexedDB. Thanks!
-bent
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
