4 ms·

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 in

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.

mlvljr 12y ago
How. Dare. You. (now please downvote me)
blablabla123 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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 12y ago

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

blablabla123 12y ago

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 12y ago
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 12y ago
  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 12y ago
    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.