Re: [w3c/IndexedDB] Allow more explicit control over transaction lifetimes (#34)

Putting my hat in the ring here for more control over transaction lifetimes and/or better comparability with promises/async/await.

My use case is the implementation of an abstract data structure, think linked list, or tree, with persistence and encryption-at-rest. In practice that means I need to be able to read a node in my structure from IndexedDB, decrypt it (which is an async operation) and then use the decrypted content to identify which _next_ node to load from IndexedDB to traverse my data structure.

Say I want to give transaction semantics to a list reorder, or tree insert operation, I will have to read and write a number of entries from IndexedDB and further entries based on encrypting those entries. All of which I can’t do at the moment because of the auto commit behaviour.

I can live with either an explicit `txn.commit()` API or a “predicate pushdown” variant like the `txn.waitUntil(Promise)` proposal in https://github.com/inexorabletash/indexeddb-promises#advanced-usage 

The goal here is to provide special-purpose data management APIs that support transparent encryption-at-rest in scenarios where a simple (and today ubiquitous) device-level encryption is not satisfactory (e.g. when devices are shared among multiple users with the same system “login”).

Aside from the consistency guarantees that I can’t implement today, this works quite well already. I’d love to be able to offer this as a proper safe solution with official Web API support.

I’m happy to elaborate or answer any further questions on this.

 Thanks! <3

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/34#issuecomment-841243199