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

On Tue, May 18, 2010 at 1:00 PM, Nikunj Mehta <nikunj@o-micron.com> wrote:
>
> On May 18, 2010, at 12:46 PM, Jonas Sicking wrote:
>
>> 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.
>
> Here's some text from the existing spec:
>        If these steps are not called with a list of database objects
>                Acquire a lock on the entire database.
>
> Is there confusion about the meaning of "acquiring a lock on the entire database?"

Yes. Especially given the language in step 2.

However note that the proposal we made, the locking level is moved
from the database-open call to the transaction-open call. This in
order to allow the page to just open the database at the start of the
page (and potentially upgrade it to its required version). The
database can then be left open for as long as the user is on the page.
This means that for any given interaction with the database only one
level of asynchronous call is needed.

>>> 2. Produce events when an application changes the version so that other tabs of the application are alerted
>>
>> How?
>
> Spec text could be written if this serves a purpose.

What functionality are you proposing?

>>> 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.
>
> Since there is no restriction on what libraries can do, one could do seemingly contrary things.
>
> Take an example. Say we want to change the content of a compound index, e.g., the order of attributes in the index. This requires changing the contents of the index. It also requires translation of the request to match the sequence of properties being stored in the index. A library can keep extra data to perform translation where it is required. This sort of stuff is done in many applications, so it is not unimaginable that someone would want to do it with IndexedDB.

I still don't understand why this is considered "performing an
incompatible change". It seems to me that if the user has a version of
the application loaded which is able to "keep extra data to perform
translation where it is required", then it isn't an incompatible
change. So in this case I would say that the application should just
leave the version number unchanged.

Granted, it's a little hard to follow the example given that we don't
have compound indexes in the spec, so maybe I'm missing something?

>>> 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.
>
> The version is book-keeping support in IndexedDB for an application. I don't see why an application should be forced to keep the version ID the same after schema upgrades. As a use case, an application may queue up schema upgrades based on version numbers.

I think asking "[Why should the application] be forced to keep the
version ID the same" is the wrong question. I'd rather ask "why would
you bother changing the version number on a compatible change"?

Like Jeremy, I don't understand what functionality the version number,
as specced, supplies. I.e. how does it make it easier for applications
to update the database scheme?

/ Jonas

Received on Tuesday, 18 May 2010 21:49:22 UTC