Is this still maintained?

[pombredanne]

Hi:
Is this project still maintained and alive? or what?
And is this fork the successor? https://github.com/nedbhq/nedb-core

Thanks!

[PopovMP]

It looks like that. I donated to the project recently. I did not even receive a response.

[marcusjwhelan]

I was thinking. What if someone rewrote the project in Typescript? I wrote nedb-shell in Typescript for nedb. NeDB is simple enough for the purpose we are using it for and don't need any extra functionality at the moment so the project really isn't dead just because nothing is happening on it. But I was thinking what if there was a new javascript database that had encryption and compression along with decryption and decompression for saving data. I am sure with node ^6.9.x that a lot more can be done.

[pombredanne]

I decided to pass using this fine code entirely for me. I wished it were not the case, but I donot base my maintained open source projects on top on non maintained open source projects unless I am up to take over the maintenance.... and I was not ready for this here. @louischatriot I think it is sad you did not manage to set up some orderly transition. R.I.P. nedb :)

[nilskp]

This may be an option, although I haven't used it.

https://erikolson186.github.io/zangodb/

[marcusjwhelan]

@nilskp That could be for browser apps but not Electron and having the persistent database.

[erikolson186]

@marcusjwhelan It should be able to be used and persisted when run within a BrowserWindow? IndexedDB is pretty fast, and uses a data storage format more storage efficient and capable than JSON.

[wangxuepeng]

Is this project still maintained? I want to know also.

[louischatriot]

@pombredanne and others - NeDB is still maintained for bugfixes, and bugfixes only, as I am now satisfied by the feature set and flexibility to build upon NeDB (i.e. I see low to negative value in expanding the core feature set vs letting it be done by developers).

FWIW, I did try to find a successor (as I have limited time) but the search was unfortunately fruitless, and I now don't even have time to look for one anymore ...

[louischatriot]

(leaving this open for others)

[pombredanne]

@louischatriot thanks for chiming in :) this is unfortunate but a good answer ! God speed!

[ekryski]

@louischatriot if you are up for transferring to the FeathersJS org our core team would be down for maintaining. We have a team of 6, use it pretty extensively and are looking to expand on it for browser support and React Native. Feel free to send me a private note at e[dot]kryski[at]gmail.com. Possibly @pi0 would like to bring nedb-core and this together so that we have less fragmentation?

[ekryski]

@louischatriot I had misspelled my email. Corrected now.

[marcusjwhelan]

@ekryski If your team does inherit the project, myself and another are working on a shell for the project and would love to create a shell to use in the browser. Also if you all upgraded the project to Typescript that would be great news for us and we could incorporate generic types into our project. Also the project is in early stages and taking in requests to fulfill can help create a better shell. nedb-shell

[jeremythuff]

Is there an update on this? I too would be interested in contributing to any sort of rewrite. It would be nice if this functionality came in a more observable flavor as opposed to the whole callback thing.

[pi0]

Hi there. We made a fork of awesome nedb into nedb-core to support React Native platform as well. Unfortunately i don't have enough time to donate on it anymore but would be happy accepting new contributors :)

[ekryski]

@pi0 we should chat. Would you be able/willing to transfer it? I forked your nedb-core and started creating nedb-react-native, nedb-browser, and nedb-node modules. With the idea that nedb-core is all of the stuff that can be used on any of those platforms.

[marcusjwhelan]

@ekryski @pi0 I am currently working on a different version written in Typescript with another developer. I forked the binary tree written in nedb and rewrote most of it and added some extra restrictions and capabilities. binary-type-tree.

[pi0]

Maybe it could better create a group chat sharing ideas :D

[ekryski]

@pi0 @marcusjwhelan did you have a suggestion? If you guys wanted to you could jump in http://slack.feathersjs.com/ and we could chat in there. Open to other suggestions, or just keep it up in a separate github issue on nedb-core?

[marcusjwhelan]

I was going to suggest to create a slack channel but if there is already one I will join. Maybe create a specific channel for this though.

[pi0]

I'm in too :)

[marcusjwhelan]

@pombredanne @jeremythuff @029xue @PopovMP We did make an alternate. TeDB. It is not exactly like nedb. It should be able to handle very large collections. It has not been benchmarked. Also have a collaboration with people from the Feathersjs team for future upgrades. There is an example storage driver for node's FS lib int he spec/example directory.

[pombredanne]

@marcusjwhelan Thanks. For me I switched to use sequelize.js ;)

[martinsookael]

As Javascript is poised with having very little dependencies that are considered "ready", I think it's refreshing to see a project that has reached a level where it's stable, with it's minuses and plusses.

I'm using it in several projects, and it works precisely as advertised in the specs. Hey at least it has specs!

[AldoMX]

Any news about the transfer to FeatherJS? It's almost been a year already.

Anyway, I'm leaving my notes here to help people get a better grasp of the status quo without spending as much time as I did:

1. NeDB-core - This seems to be the oldest alternative, unfortunately the issues tab is disabled and the project looks unmaintained, so it is a bit complicated to see what's going on. They really did an impressive job expanding the original NeDB to support different environments (ex. React Native or the Browser) and did their fair share of bugfixes, but I wouldn't use if for new projects. Although I wouldn't ditch it (yet) for existing projects either.

2. TeDB - They're not a 1:1 replacement but that's actually good because they take a different approach that takes advantage of TypeScript and takes inspiration in other projects like NeDB-core, for example, they actually require you to use a storage driver, ex. Memory (any), Filesystem (Node.JS), IndexedDB (Browser), AsyncStorage (React Native), etc., Unfortunately they only provide a storage driver for Electron. They also have a Filesystem storage driver, but it is labelled as a mock and displaced to the examples folder. They're probably expecting the community to build the missing drivers, which means you have to pay your share of code before using this project. This is my preferred choice for new projects if you don't require a 1:1 replacement.

3. NestDB - They emerged in August 2017, their issue tracker shows a solid roadmap, but unfortunately they forgot to register the project in NPM so you can't simply do npm install nestdb. They're missing some of the fixes of NeDB-core but their roadmap shows that they're planning to incorporate them. Hopefully the NPM issue will be fixed by the time you read this. This is my preferred choice for new projects if you require a 1:1 replacement.

If the alternatives don't make sense to you, it is still valid to use the original NeDB. I would personally hope to see the fragmentation issue to go away.

[pi0]

For NeDB-core I've enabled issues section if any change we can do (And PRs welcome). Anyway, it is unmaintained now. I've transferred ownership to @ekryski. Don't know if he has any plans or alternative suggestions.

[JamesMGreene]

Thanks for the thoughtful writeup, @AldoMX.

[marcusjwhelan]

@AldoMX @pi0

Currently I am still maintaining TeDB and adding fixes tot he system. The lates is the most stable if you have not updated. As for the example storage driver the Electron Storage driver is a good example of what to try and write but not for React-Native. I will try and build in blocking and non-blocking components into the Electron db since issues do arise if you multiple async trying to update the same file location.

As for React Native I plan on writing a Storage Driver it some time this year. Right now we use TeDB at our company as our Electron DB so if any issues pop-up. This means if something is found where data is lost or corrupted this is high priority. No issues have been submitted so far.

I will say this. If you use TeDB and want to find with $gt, $gte for dates you have to save your date as a number. so dateObject.getTime(). and when you load back in you can use another method to convert back to string before placing in memory. I am always available for questions and might possibly open up as slack channel for TeDB and its other libraries suck as tedb-utils which I also use extensively.

[gajus]

Surprised no one mentioned https://pouchdb.com/.

It seems to be by far the most established alternative.

[JamesMGreene]

PouchDB is nice but has fairly different paradigms than NeDB.

[gajus]

PouchDB is nice but has fairly different paradigms than NeDB.

Can you elaborate?

[marcusjwhelan]

@gajus PouchDB from what I can tell is strictly browser based. You could not write to disk with it from what I can tell. NeDB, TeDB allow you to write to disk. This can be used with Electron or with other embedded software using JS.

[JamesMGreene]

First off, PouchDB isn't a self-contained database at all, it's an abstraction layer. That said, PouchDB can be used on-disk by either embedding a CouchDB instance (super heavyweight solution) or by using a LevelDOWN adapter (default on Node and an acceptable solution): https://pouchdb.com/adapters.html#pouchdb_in_node_js

I just think PouchDB is so overly concerned about synchronization/replication across instances and revision control that I feel like their API is much more basic in order to align with the CouchDB protocol vs having their own more expressive API on top of it for the many users who may just want to use it on a single isolated instance like NeDB.

[gajus]

I just think PouchDB is so overly concerned about synchronization/replication across instances and revision control that I feel like their API is much more basic in order to align with the CouchDB protocol vs having their own more expressive API on top of it for the many users who may just want to use it on a single isolated instance like NeDB.

Can you advice what is the best alternative to NeDB/ PouchDB if the use case is storage of a collection of objects in memory and being able to filter the collection using a DSL such as that provided by Elastic, NeDB or PouchDB?

[pi0]

This is OSS. We all have projects that have no resources / spare time to even answer issues. Let's understand and appreciate author ☺️😉

[pombredanne]

and this ticket has been open for long enough. Let me close this. If someone feels strongly about this, start a well behaved fork!
https://github.com/HalleyAssist/nedb maintained by @splitice seems quite active!

[Akumzy]

@pombredanne It does not work with Electron 6.0.0 there's an issue with ref

[beaugunderson]

@Akumzy hmm i'm using nedb with 6.0.0 and it works fine...

[Akumzy]

@beaugunderson I mean this https://github.com/HalleyAssist/nedb repo

[splitice]

I do not recommend using our repository for electron apps. I would guess that fallocate would break.

We are developing for native support on one particular platform (Linux) only.

[marcusjwhelan]

@Akumzy @pombredanne Tedb which is mentioned above was made with pure intention to work on electron. Currently using it on Electron 6.0.0 in production. The only storage driver I have written is the tedb electron storage driver. There is also a utils package.

[Akumzy]

@marcusjwhelan The doc is very confusing how can I implement new yourStorageDriverClass("users"); is there an complete sample or demo?

import * as tedb from "tedb";
// For example, I want to make Users
const UserStorage = new yourStorageDriverClass("users");
const Users = new tedb.DataStore({storage: UserStorage});

[marcusjwhelan]

@Akumzy tedb-electron-storage is the storage driver for electron. I wouldn't read the .org docs, the README.md is more up to date. I have not pushed the project any for a long time since it is at a very stable state. No issues. I have used it in production in the field for 2 years now.

As for your question though. If you read through the docs you will see I work through the example explaining everything along the way. As you see in the code you posted I created a Collection or Table named Users. Now I can operate on it just like a collection in mongodb.

In the next part of the README I show how to create an index on a field on that collection. It is a promise so handle it accordingly.

Then on to Inserting, Updating, .. etc

[leonheess]

@splitice How about creating a repository from your fork and registering it with npm?

[zhaoyao91]

https://github.com/typicode/lowdb
seems to be a reasonable alternative in some situations

[athul7744]

https://github.com/dfahlander/Dexie.js/
Very good alternative. Works on IndexedDB though.

[pubkey]

I tried to list up all client side JavaScript databases as alternatives which might be relevant as replacement for NeDB: https://rxdb.info/alternatives.html

[SuperKirik]

It looks like at the moment here is the most actual and actively maintained fork of the original NeDb: https://github.com/seald/nedb