On May 18, 2010, at 2:48 PM, Jonas Sicking wrote: > On Tue, May 18, 2010 at 1:00 PM, Nikunj Mehta <nik...@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 <nik...@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.
Would you mind proposing better spec text? > > However note that the proposal we made, the locking level is moved > from the database-open call to the transaction-open call. I will respond separately to that. Locking is performed in the spec at transaction open time, not at database open time. I am not proposing to change that. > 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? I answered this in other parts of this thread. > >>>> 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 is an incompatible change at some level, isn't it? > 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. Your approach can work too. Nevertheless, I don't want to constrain an application's behavior in this respect. > > 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? In my understanding the spec supports compound indexes and has since at least October last year. > >>>> On May 18, 2010, at 1:54 AM, Jonas Sicking wrote: >>>> >>>>> On Thu, May 13, 2010 at 10:25 AM, Shawn Wilsher <sdwi...@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? > I hope my response to this same question in the other message helps understand the use case for version.
