Re: [IndexedDB] Current editor's draft

Nikunj,

On Fri, Jul 9, 2010 at 8:21 PM, Nikunj Mehta <nikunj@o-micron.com> wrote:
>
>
> From my examples, it was clear that we need different object stores to be opened in different modes. Currently dynamic scope supports this use case, i.e., allow mode specification on a per object-store basis. Therefore, unless we decide to de-support this use case, we would need to add this ability to static scope transactions if dynamic scope transactions go out of v1.
>

I would be very grateful if you could help me understand the statement
above. Looking at your examples, we have:


function processShipment(shipment, callback) {
// we need to validate the part exists in this city first and that the
supplier is known
var txn = db.transaction(); //synchronous because requesting locks as I go along
var parts = txn.objectStore("part", IDBObjectStore.READ_ONLY);
var partRequest = parts.get(shipment.part);
partRequest.onerror = shipmentProcessingError;
partRequest.onsuccess = function(event) {
 // the required part exists and we have now locked at least that key-value
 // so that it won't disappear when we add the shipment.
 var suppliers = txn.objectStore("supplier", IDBObjectStore.READ_ONLY);
 var supplierRequest = suppliers.get(shipment.supplier);
 supplierRequest.onerror = shipmentProcessingError;
 supplierRequest.onsuccess = function(event) {
   // the required supplier exists and we have now locked that key-value
   // so that it won't disappear when we add the shipment.
   var shipments = db.objectStore("shipment", IDBObjectStore.READ_WRITE);
   var shipmentRequest = shipments.add(shipment);
   supplierRequest.onerror = shipmentProcessingError;
   shipmentRequest.onsuccess = function(event) {
     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;
   }
 }

If I understand things right, this example processes a new shipment:
it checks that the part and supplier exist and then adds the new
shipment to the appropriate object store. And you are claiming that if
we leave dynamic transactions out of v1, then we need to de-support
this use case. Is this correct?

Now, would the code below support the same use case?

function processShipment(shipment, callback) {
  // We open a READ_WRITE transaction since we need to update the
shipments object store.
  var txnRequest = db.openTtransaction("part", "supplier",
"shipments", IDBObjectStore.READ_TRANSACTION);

  txnRequest.onsuccess = function(event) {
    var txn = event.transaction;
    var parts = txn.objectStore("part");
    var partRequest = parts.get(shipment.part);

    partRequest.onsuccess = function(event) {
      // the required part exists
      var suppliers = txn.objectStore("supplier");
      var supplierRequest = suppliers.get(shipment.supplier);

      supplierRequest.onsuccess = function(event) {
        // the required supplier exists
       var shipments = db.objectStore("shipment");
       var shipmentRequest = shipments.add(shipment);

       shipmentRequest.onsuccess = function(event) {
         var key = event.result;
         txnRequest.oncommit = function() {
           callback(key); // which is the key generated during storage
         }
       }
     }
   }
}

So if the above supports the same use case (albeit by allowing less
concurrency), then we dropping dynamic transactions doesn't mean we
lose this use case. Is this right? Are there any other use cases you
think we could lose? I could not find them in your examples.

Thanks,
Andrei

Received on Monday, 12 July 2010 12:23:45 UTC