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

On Thu, Jun 10, 2010 at 6:15 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Thu, Jun 10, 2010 at 6:31 AM, Andrei Popescu <andreip@google.com>
> wrote:
> > 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.
>
> We could technically enforce that other transactions won't be allowed
> to start until the event has fired in all windows that has the
> database open.
>

Sure, but I can't think of any reason you'd want such semantics.  Can you?

Either way though, I'm wondering how this relates to the fact that you
> can (in our proposal, I'm unclear what the current draft allows) have
> several writing transactions at the same time, as long as they operate
> on different tables. Here another transaction might have already
> started by the time another transaction is committed. Be that in this
> window or another.
>

That's only true of dynamic transactions.  Mikeal, were you planning on
using static or dynamic transactions?  If it's the latter, then I think
Jonas has a good point and that this API might not help you after all.

That said, I can think of other uses for notifications other windows have
committed a transaction.  But I think many if not all of them can be
emulated with postMessage...

I guess I'm starting to lean towards thinking this is extra API surface area
for limited gain.

J