Re: [IndexedDB] Current editor's draft

On Fri, Jul 9, 2010 at 6:27 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> I also did not hear from you about explicit commits. Did that mean that you agree with that part of my proposal? There are several examples where it makes sense to explicitly commit, although it is automatic in some cases.
>
> I haven't yet had time to analyze this. I wanted to do so before
> commenting. I don't have time right now, but will do so tomorrow.

Ok, I looked at the example functions that you supplied in the
original email in this thread.

As far as I can see, in every instance where you are calling
.commit(), if you simply removed the call to .commit() that would not
change the behavior of the code. Am I missing something?

The only exception is the following code in processShipment:

     var txnRequest = event.transaction.commit();
     // before the callback, commit the stored record
     var key = event.result;
     txnRequest.oncommit = function() {
       callback(key); // which is the key generated during storage
     }
     txnRequest.onerror = shipmentProcessingError;

where you are using the return value from .commit(). However I suspect
there is a bug in this code as .commit() in your proposal is defined
to return void. And even if it does return an IDBRequest, that object
does not have an oncommit property. I suspect you intended the code to
say:

     event.transaction.commit();
     // before the callback, commit the stored record
     var key = event.result;
     event.transaction.oncomplete = function() {
       callback(key); // which is the key generated during storage
     }
     event.transaction.onerror = shipmentProcessingError;

With this fix, here too the call to .commit() seems to be removeable
without affecting behavior.

Please let me know if I'm missing something?

/ Jonas

Received on Saturday, 10 July 2010 16:56:15 UTC