W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: [IndexedDB] Event on commits (WAS: Proposal for async API changes)

From: Andrei Popescu <andreip@google.com>
Date: Thu, 10 Jun 2010 14:31:01 +0100
Message-ID: <AANLkTinKxb6YAj8-vyStL3VXNqs03WPUBFZqryQdhgWj@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: Mikeal Rogers <mikeal.rogers@gmail.com>, Webapps WG <public-webapps@w3.org>
On Thu, Jun 10, 2010 at 1:39 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
> Splitting into its own thread since this isn't really connected to the new
> Async interface and that thread is already pretty big.
> On Wed, Jun 9, 2010 at 10:36 PM, Mikeal Rogers <mikeal.rogers@gmail.com>
> wrote:
>> I've been looking through the current spec and all the proposed changes.
>> Great work. I'm going to be building a CouchDB compatible API on top
>> of IndexedDB that can support peer-to-peer replication without other
>> CouchDB instances.
>> One of the things that will entail is a by-sequence index for all the
>> changes in a give "database" (in my case a database will be scoped to
>> more than one ObjectStore). In order to accomplish this I'll need to
>> keep the last known sequence around so that each new write can create
>> a new entry in the by-sequence index. The problem is that if another
>> tab/window writes to the database it'll increment that sequence and I
>> won't be notified so I would have to start every transaction with a
>> check on the sequence index for the last sequence which seems like a
>> lot of extra cursor calls.
> It would be a lot of extra calls, but I'm a bit hesitant to add much more
> API surface area to v1, and the fall back plan doesn't seem too
> unreasonable.
>> What I really need is an event listener on an ObjectStore that fires
>> after a transaction is committed to the store but before the next
>> transaction is run that gives me information about the commits to the
>> ObjectStore.
>> Thoughts?
> To do this, we could specify an
> IndexedDatabaseRequest.ontransactioncommitted event that would
> be guaranteed to fire after every commit and before we started the next
> transaction.  I think that'd meet your needs and not add too much additional
> surface area...  What do others think?

It sounds reasonable but, to clarify, it seems to me that
'ontransactioncommitted' can only be guaranteed to fire after every
commit and before the next transaction starts in the current window.
Other transactions may have already started in other windows.

Received on Thursday, 10 June 2010 13:31:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:08 UTC