On Thu, Apr 17, 2014 at 2:04 PM, Domenic Denicola <[email protected]> wrote: > From: Joshua Bell <[email protected]> >> How much of leveldb's API you consider part of the minimum set - write >> batches? iterators? snapshots? custom comparators? multiple instances per >> application? And are IDB-style keys / serialized script values appropriate, >> or is that extra overhead over e.g. just strings? > > This is my question for Tim as well. My personal hope has always been for > something along the lines of async local storage [1], but that omits a lot > of LevelDB's API and complexity, so presumably it goes too far for LevelDB > proponents. > > [1]: https://github.com/slightlyoff/async-local-storage
A big question here is "do you need transactional integrity/atomic mutations?" These things will always make the API more complex and so it gets in the way if you don't need it. But not having them means exposing yourself to race conditions, especially as your application grows more complex or simply if the user has your application open in two separate tabs. My experience is that people need transactional integrity more often than they think they do. The API at [1] punts on transactional integrity entirely. It does not allow you to perform complex operations like "increase the value at 'unreadEmailCount' by one" in a race-free manner. / Jonas
