Add support for transactions/atomic operations? about localforage

[peterbe]

Might be hard on the removeItem() or clear() but I could actually make good use of this feature since I store both key-value data and then lastly I store a list of all keys. If either of these fail, it would leave my data in "conflict".
Not desperate but it would be impressive a feature.

[tofumatt]

At this point calls to the public data API are routed through ready(), so this is quite possible provided we had a queue as well... and a way of rolling back changes.

It's likely quite out-of-scope for a library as simple as localForage. I'll leave this open for a bit longer in case someone wants to take a crack at it though.

[tofumatt]

Right now this seems pretty out-of-scope for localForage. An entire transaction solution would be heavyweight and not in the spirit of the simplistic nature of localForage.

I think I'll close this for now, but a PR would be welcome in the future.

[jampy]

sorry, but why is this heavywheight? both WebSQL and IndexedDB support transactions natively AFAIK, so localforage could just use them.

Okay, this won't work with localStorage driver, but even then an ADVANCED_MODE flag or similar (as proposed by someone else) could restrict usage to the other IndexedDB/WebSQL drivers.

[tofumatt]

As mentioned, I would be open to a pull request but especially as we want version 1.0 to support localStorage, we would need to support transactions for it. Or this would have to be a feature we land in a 2.0, when maybe we won't use localStorage anymore.

[ccorcos]

Just wanted to chime in with my use-case. When a user is offline, we save database entries in the browser. When the user comes back online, we sync that up with the server. However, since browser windows share state, without transactions, we can end up committing things twice...

[shmilyoo]

really need atomic transaction api.
Many scenarios will encounter this situation of read and write conflicts