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

Yes.  Sorry for not being clear.

On Thu, Jun 10, 2010 at 2:31 PM, 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.
>
> Andrei
>