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

On Tue, May 18, 2010 at 11:31 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, May 18, 2010 at 2:57 PM, Nikunj Mehta <nikunj@o-micron.com> wrote:
> >
> > On May 18, 2010, at 2:33 PM, Jeremy Orlow wrote:
> >
> > On Tue, May 18, 2010 at 9:36 PM, Shawn Wilsher <sdwilsh@mozilla.com>
> wrote:
> >>
> >> On 5/18/2010 1:02 PM, Nikunj Mehta wrote:
> >>>
> >>> A database connection that locks the entire database cannot be opened
> if
> >>> there is another database connection that locks at least one database
> >>> object, e.g., an index or object store.
> >>
> >> So basically, as long as some connection holds a database lock, you
> won't
> >> be able to do any upgrade.
> >
> > Sure, but this is true of Jonas' proposal as well.
> >
> > But to me it is a no-op. The spec already does what Jonas is proposing -
> > lock out users when an upgrade is in progress and wait to start an
> upgrade
> > if a user is using the application.
>
> Note that in our proposal, having a database open does not hold any
> locks. It simply holds metadata (such as objectStore and index names)
> in memory. It is totally ok for the application to open the database
> when the user initially loads the page, and never close it until the
> user leaves the page.
>
> In fact, I would encourage users to do this since it allows for
> reading data using a single level asynchronous callbacks, and so makes
> for very readable code.
>
> Because our proposal is incompatible with the versioning mechanism
> that the spec uses, I would propose that we first decide on if
> mozillas proposal should be accepted before we decide on what
> versioning mechanism we should use.
>

Agreed.  Let's table this for now.

Nikunj, can you please look at the "[IndexDB] Proposal for async API
changes" thread?

Thanks,
Jeremy