From what I can make out, this won't work under cluster, right? You won't get new data written from one worker in another. It also has no locking so you can easily corrupt the database if you access it from multiple programs at once (or with cluster).
It's not supposed to work with cluster and using it with multiple programs that update/remove/insert docs will cause unexpected behaviour, although no data corruption since the datafile is append-only.
But if you need multiple programs to use your DB at once you need a more powerful solution such as MongoDB. The goal of NeDB is to bring DB features to desktop apps or low concurrency webapps, not replace Mongo and the like.
No I get that, I'm not saying it should support those things, just saying you should probably document it clearly. People don't like to lose data.
And append-only doesn't make you immune to corruption. There's still a possibility of two processes writing at the same time corrupting what gets written to the file.
Perhaps you should provide an option to have the db itself running as a child process (via cluster), and CRUD statements are actually proxied to that process (via a Unix pipe or socket) instead of updating the data directly in the process' state. This would work well as an extension.
I see why you would think that, this part of the README is not well formulated and I'll change it. What I mean is that is similar to SQLite since it is an embedded database, but the key difference is that it's pure JS so you don't need to compile or install anything, which makes it very handy for Node Webkit, low concurrency Node.js webapps an rapid prototyping.
I totally get the use-case. As the author of Perl's DBD::SQLite I know exactly how high the demand for this sort of thing is. I think it's a great project and wish you luck with it. (and if you ever decide to lock the files, I'm also the author of node's fs-ext library which provides flock() support).
Comments
From what I can make out, this won't work under cluster, right? You won't get new data written from one worker in another. It also has no locking so you can easily corrupt the database if you access it from multiple programs at once (or with cluster).
It's not supposed to work with cluster and using it with multiple programs that update/remove/insert docs will cause unexpected behaviour, although no data corruption since the datafile is append-only.
But if you need multiple programs to use your DB at once you need a more powerful solution such as MongoDB. The goal of NeDB is to bring DB features to desktop apps or low concurrency webapps, not replace Mongo and the like.
No I get that, I'm not saying it should support those things, just saying you should probably document it clearly. People don't like to lose data.
And append-only doesn't make you immune to corruption. There's still a possibility of two processes writing at the same time corrupting what gets written to the file.
Perhaps you should provide an option to have the db itself running as a child process (via cluster), and CRUD statements are actually proxied to that process (via a Unix pipe or socket) instead of updating the data directly in the process' state. This would work well as an extension.
From reading the description if you need this functionality you should move to something else as the functionality you mentioned is out of it's scope.
Just saying, I think it should be documented in the README.md as SQLite would be fine in those scenarios, which it tries to compare to.
I see why you would think that, this part of the README is not well formulated and I'll change it. What I mean is that is similar to SQLite since it is an embedded database, but the key difference is that it's pure JS so you don't need to compile or install anything, which makes it very handy for Node Webkit, low concurrency Node.js webapps an rapid prototyping.
I totally get the use-case. As the author of Perl's DBD::SQLite I know exactly how high the demand for this sort of thing is. I think it's a great project and wish you luck with it. (and if you ever decide to lock the files, I'm also the author of node's fs-ext library which provides flock() support).