如何在没有自动提交事务的情况下将诺言与IndexedDB一起使用？

Question

在没有事务自动提交的情况下，有没有办法使用带有承诺和异步/等待的IndexedDB？我知道您不能在事务处理过程中做诸如获取网络数据之类的事情，但是我在此主题上在线发现的所有内容都表明，如果仅将其包装在Promise中，IndexedDB应该仍然可以工作。

但是，在我的测试中（Firefox 73），我发现仅将请求的onsuccess包装在Promise中就足以使交易在Promise执行之前自动提交，而使用原始代码时，相同的代码也可以工作IndexedDB API。我能做什么？

这是我的代码的简化的最小示例。

const {log, error, trace, assert} = console;

const VERSION = 1;
const OBJ_STORE_NAME = 'test';
const DATA_KEY = 'data';
const META_KEY = 'last-updated';

function open_db(name, version) {
    return new Promise((resolve, reject) => {
        const req = indexedDB.open(name, version);
        req.onerror = reject;
        req.onupgradeneeded = e => {
            const db = e.target.result;
            for (const name of db.objectStoreNames) {db.deleteObjectStore(name);}
            db.createObjectStore(OBJ_STORE_NAME);
        };
        req.onsuccess = e => resolve(e.target.result);
    });
}
function idbreq(objs, method, ...args) {
    return new Promise((resolve, reject) => {
        const req = objs[method](...args);
        req.onsuccess = e => resolve(req.result);
        req.onerror = e => reject(req.error);
    });
}
async function update_db(db) {
    const new_time = (new Date).toISOString();
    const new_data = 42; // simplified for sake of example

    const [old_data, last_time] = await (() => {
        const t = db.transaction([OBJ_STORE_NAME], 'readonly');
        t.onabort = e => error('trans1 abort', e);
        t.onerror = e => error('trans1 error', e);
        t.oncomplete = e => log('trans1 complete', e);
        const obj_store = t.objectStore(OBJ_STORE_NAME);
        return Promise.all([
            idbreq(obj_store, 'get', DATA_KEY),
            idbreq(obj_store, 'get', META_KEY),
        ]);
    })();
    log('fetched data from db');
    // do stuff with data before writing it back

    (async () => {
        log('beginning write callback');
        const t = db.transaction([OBJ_STORE_NAME], 'readwrite');
        t.onabort = e => error('trans2 abort', e);
        t.onerror = e => error('trans2 error', e);
        t.oncomplete = e => log('trans2 complete', e);
        const obj_store = t.objectStore(OBJ_STORE_NAME);
        // This line works when using onsuccess directly, but simply wrapping it in a Promise causes the
        // transaction to autocommit before the rest of the code executes, resulting in an error.
        obj_store.get(META_KEY).onsuccess = ({result: last_time2}) => {
            log('last_time', last_time, 'last_time2', last_time2, 'new_time', new_time);
            // Check if some other transaction updated db in the mean time so we don't overwrite newer data
            if (!last_time2 || last_time2 < new_time) {
                obj_store.put(new_time, META_KEY);
                obj_store.put(new_data, DATA_KEY);
            }
            log('finished write callback');
        };



        // This version of the above code using a Promise wrapper results in an error
        // idbreq(obj_store, 'get', META_KEY).then(last_time2 => {
        //     log('last_time', last_time, 'last_time2', last_time2, 'new_time', new_time);
        //     if (!last_time2 || last_time2 < new_time) {
        //         obj_store.put(new_time, META_KEY);
        //         obj_store.put(new_data, DATA_KEY);
        //     }
        //     log('finished write callback');
        // });



        // Ideally, I'd be able to use await like a civilized person, but the above example
        // shows that IndexedDB breaks when simply using promises, even without await.
        // const last_time2 = await idbreq(obj_store, 'get', META_KEY);
        // log('last_time', last_time, 'last_time2', last_time2, 'new_time', new_time);
        // if (!last_time2 || last_time2 < new_time) {
        //     obj_store.put(new_time, META_KEY);
        //     obj_store.put(new_data, DATA_KEY);
        // }
        // log('finished write callback');
    })();
    return [last_time, new_time];
}

open_db('test').then(update_db).then(([prev, new_]) => log(`updated db timestamp from ${prev} to ${new_}`));

Answer 1

安排围绕交易的承诺，而不是单个请求。

如果这会导致您的设计出现问题，并且您仍要使用indexedDB，请围绕它进行设计。重新评估您是否需要事务安全性或是否需要针对多个请求实际重用一个事务，而不是创建每个事务仅包含几个请求的多个事务。

与产生少量具有大量请求的事务相比，在每个事务中产生具有少量请求的大量事务几乎没有开销。唯一真正关心的是一致性。

等待着是变相的产物。没有请求挂起时，indexedDB事务超时。收益会导致时间间隔，因此交易将超时。