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

I have pointed out three options when dealing with upgrades and concurrency [1] in a thread started by Pablo and Shawn 6 months ago [2]:

# Allow special DDL like operations at connection time in a special transaction with spec-based versioning of "schema"
# Combine DDL and DML in ordinary transactions, and app-managed versioning of "schema"
# Allow DDL like operations in a special transaction at any time

We went with the middle option after some amount of analysis and discussion.

On May 13, 2010, at 10:25 AM, Shawn Wilsher 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).

In other words, the schema changed in an incompatible way.

> 
> 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).

The spec merely asks that implementations provide the version number that is in play when the application requests it. The spec does not mandate that the version stay the same after the database is opened.

Perhaps we could produce an event if the version number changes so that an application has an opportunity to deal with that. What would the problem be with this approach?

[1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/1180.html
[2] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0927.html

Received on Tuesday, 18 May 2010 20:30:52 UTC