On Fri, Jul 9, 2010 at 6:27 PM, Jonas Sicking <[email protected]> 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
