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

On Tue, May 18, 2010 at 12:37 PM, Nikunj Mehta <nikunj@o-micron.com> wrote:
> 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.

Will locking the database prevent others from creating new
objectStores? Step 2 only talks about acquiring locks on the existing
database objects.

> 2. Produce events when an application changes the version so that other tabs of the application are alerted

How?

> 3. Through a library develop sophisticated means of performing incompatible changes without breaking applications using an earlier version of the indexedDB.

I don't understand, "performing incompatible changes" seems contrary
to "without breaking applications using an earlier version". I don't
see how you could to both at the same time in the general case.

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

If the schema upgrade is compatible with the existing one, then no
need to update the version. I thought the whole point of the version
identifier was to assist in making incompatible changes.

/ Jonas

Received on Tuesday, 18 May 2010 19:47:18 UTC