[DogeDogeDoge]

This has like zero fault tolerancy and by zero i mean none. Don't even push flush to disk... it has a level of a in memory hash of persistence and is totally insecure in terms of multithreading. As a Toy to show off yeah could work but... in the very end of the day. You can minus me but this is crap.

[blablabla123]

I think the idea is cool, actually I once worked on something similar in Go, very small code base. And adding flushing, caching and thread-safety is no black art. The charming thing here is that, once severe Data errors happen, one can easily recover from them using a simple Editor.

Imagine how to fix low-level data corruption on your <Insert your DBMS name> Server.

[couchand]

once severe Data errors happen, one can easily recover from them using a simple Editor.

Unfortunately, in this case, you can't necessarily. One of the issues here is that holding on to handles to multiple collections doesn't do what it seems to, and also doesn't fail. Try running this:

    var low = require('lowdb');

    var foo = low('foo');
    low('bar');

    low.on('add', function(collection) {
        console.log("this should be foo:", collection);
    });

    foo.insert({ name: 'foo' });

[typicode]

Actually, in my code I always start with low():

  low('foo').insert({ name: 'foo' })
  low('bar').insert({ name: 'bar' })
  low('foo').insert({ name: 'foo' })

So never really considered this way of writing or had this bug.

But I can see that it's a flaw and unexpected behavior. I'm adding this to the enhancements for the next version.

Thanks for spotting it :)

[typicode]

Just a little update. I've released LowDB 0.4.0 which is a complete rewrite of the project.

It fixes some initial flaws/bugs and includes some new features. Also, writing is now fault-tolerant and fully asynchronous.

[mlvljr]

How. Dare. You. (now please downvote me)