2012-06-22 36 views
5

uso dos eventos diferentes para la devolución de llamada para responder cuando la transacción IndexedDB termina o tiene éxito:Indexeddb: ¿Diferencias entre onsuccess y oncomplete?

Digamos ... DB: IDBDatabase objeto, tr: IDbTransaction objeto, SO: IDBObjectStore objeto

tr = db.transaction(os_name,'readwrite'); 
os = tr.objectStore(); 

caso 1:

r = os.openCursor(); 
r.onsuccess = function(){ 
    if(r.result){ 
     callback_for_result_fetched(); 
     r.result.continue; 
    }else callback_for_transaction_finish(); 
} 

caso 2:

tr.oncomplete = callback_for_transaction_finish(); 

Es un desperdicio si ambos funcionan de manera similar. Entonces, ¿puedes decirme, hay alguna diferencia entre ellos?

+0

Esta es una gran pregunta – buley

Respuesta

8

Si bien es cierto estas devoluciones de llamada funcionan de manera similar que no son los mismos: la diferencia entre onsuccess y oncomplete es que las transacciones complete pero las solicitudes, que se hacen en esas transacciones, son successful.

oncomplete solo se define en the spec como relacionado con una transacción. Una transacción no tiene una devolución de llamada onsuccess.

+0

quiso decir que cuando una transacción es completa, eso no quiere decir todo el proceso es exitoso, ¿verdad? – Dagon

+2

sí, significa que la transacción ha salido del alcance y se ha comprometido – buley

8

sentimos por levantar todo un viejo hilo, pero es el cuestionamiento es un buen punto de partida ...

He buscado una pregunta similar, pero en un caso de uso diferente de bits y realmente no encontró buenas respuestas o incluso uno engañoso.

Piense en un caso de uso cuando necesite hacer varias escrituras en el objeto Almacén de incluso en varias. Definitivamente no desea que administre cada escritura individual y su propio éxito y eventos de error. Ese es el significado de la transacción y esta es la aplicación (correcta) de la misma para IndexedDB:

var trx = dbInstance.transaction([storeIdA, storeIdB], 'readwrite'), 
    storeA = trx.objectStore(storeIdA), 
    storeB = trx.objectStore(storeIdB); 

    trx.oncomplete = function(event) { 
     // this code will run only when ALL of the following requests are succeed 
     // and only AFTER ALL of them were processed 
    }; 
    trx.onerror = function(error) { 
     // this code will run if ANY of the following requests will fail 
     // and only AFTER ALL of them were processed 
    }; 

    storeA.put({ key:keyA, value:valueA }); 
    storeA.put({ key:keyB, value:valueB }); 
    storeB.put({ key:keyA, value:valueA }); 
    storeB.put({ key:keyB, value:valueB }); 

pista a este entendimiento es que se encuentran en la siguiente declaración del W3C spec:

Para determinar si una transacción se ha completado con éxito, escuche el evento completo de la transacción en lugar del evento de éxito de una solicitud particular, porque la transacción aún puede fallar después de que se desata el evento de éxito.

+0

justo lo que estaba buscando. supongo que objectStore.onsuccess y objectStore.oncomplete también se pueden usar para multi .add,. get, .put, etc ... en el almacén de objetos dado. –

2

sólo me advierten que no hay que conseguir un garentee trx.oncomplete éxito significa que los datos se escriben en el disco/base de datos:

Estamos viendo un problema con trx.oncomplete donde los datos son no está escrito en el db en el disco. FireFox tiene una explicación de lo que hicieron que causa este problema aquí: https://developer.mozilla.org/en-US/docs/Web/API/IDBTransaction/oncomplete

Parece que windows/edge también está teniendo el mismo problema. Básicamente, no hay garantía de que su aplicación tenga datos escritos en la base de datos, si/cuando el usuario decide matar o apagar el dispositivo. Incluso hemos intentado esperar hasta 15 minutos antes de cerrar en algunos casos y no hemos visto los datos escritos. Para mí, siempre me gustaría asegurarme de que la escritura de datos se complete y esté comprometida.

¿Hay otras soluciones para una base de datos real persistente, o mejoras en el IndexedDB más allá FF complemento experimental ...