Re: [IndexedDB] What happens when the version changes?

If the use case here is to avoid tripping up on schema changes, then:

1. Lock the database when starting a database connection. This is the non-sharing access mode defined in 3.2.9 as the first option under step 2.
2. Produce events when an application changes the version so that other tabs of the application are alerted
3. Through a library develop sophisticated means of performing incompatible changes without breaking applications using an earlier version of the indexedDB.

More below.

On May 18, 2010, at 1:54 AM, Jonas Sicking wrote:

> On Thu, May 13, 2010 at 10:25 AM, Shawn Wilsher <sdwilsh@mozilla.com> wrote:
>> On 5/13/2010 7:51 AM, Nikunj Mehta wrote:
>>> 
>>> If you search archives you will find a discussion on versioning and that
>>> we gave up on doing version management inside the browser and instead leave
>>> it to applications to do their own versioning and upgrades.
>> 
>> Right, I'm not saying we should manage it, but I want to make sure we don't
>> end up making it very easy for apps to break themselves.  For example:
>> 1) Site A has two different tabs (T1 and T2) open that were loaded such that
>> one got a script (T1) with a newer indexedDB version than the other (T2).
>> 2) T1 upgrades the database in a way that T2 now gets a constraint violation
>> on every operation (or some other error due to the database changing).
>> 
>> This could easily happen any time a site changes the version number on their
>> database.  As the spec is written right now, there is no way for a site to
>> know when the version changes without reopening the database since the
>> version property is a sync getter, implementations would have to load it on
>> open and cache it, or come up with some way to update all open databases
>> (not so fun).
> 
> I think what we should do is to make it so that a database connection
> is version specific.

This is draconian and does not permit compatible schema upgrades, which a perfectly normal application is willing to make.

> When you open the database connection (A) the
> implementation remembers what version the database had when it was
> opened. If another database connection (B) changes the version of the
> database, then any requests made to connection A will fail with a
> WRONG_VERSION_ERR error.

I would not support this change.

> 
> The implementation must of course wait for any currently executing
> transactions in any database connection to finish before changing the
> version.
> 
> Further the success-callback should likely receive a transaction that
> locks the whole database in order to allow the success callback to
> actually upgrade the database to the new version format. Not until
> this transaction finishes and is committed should new connections be
> allowed to be established. These new connections would see the new
> database version.

In case a database is being upgraded, the application is advised to begin a transaction with the entire database locked thereby preventing problems with partial schema upgrades being visible to applications thus breaking them. This behavior is already specced. Is there anything missing in the text about it?

Received on Tuesday, 18 May 2010 19:38:01 UTC