Is there any way to `close` a datastore?

[dzcpy]

So after pending tasks are finished, invoke the close callback and client side can be noticed that the datastore is closed? It's useful when you want to drop or rename the data file without shutting down the server entirely.

[bhaveshgohel]

Same Question... @louischatriot is there anyway to close the datastore? And Does it free in-memory that occupied when loading database?

[zevero]

I ran into this when I was doing https://github.com/zevero/passwordless-nedbstore

In order to run the passwordless-tokenstore test multiple nedb instances will open the same file. This is not handled very well. Since I did not find a possibility to close the datastore I had to make a hack, so that all the tests get always the first nedb instance.

In practice I dont need a close, but for testing purposes it would be nice!

[zevero]

I have another issue: Just made an app with a single test user. Now that I want to finish it, I like the idea to use a seperate db for every user. But there can be thousands of them (hopefully).

For now I will cache the opened dbs for consecutive access. On the long term it would be nice to close it again (ideally autoclose after some timeout).

[simon-p-r]

I have seen your hack but this is feature should definitely be part of nedb's api.

[jnovack]

From the docs...

You can manually call the compaction function with yourDatabase.persistence.compactDatafile which takes no argument. It queues a compaction of the datafile in the executor, to be executed sequentially after all pending operations. The datastore will fire a compaction.done event once compaction is finished.

Does this not work?

[mitevdev]

Close database feature would be very useful when used on server side. Assume the server generates and persist events on regular basis which later on could be queried for some reasons. The best solution would be to load database on demand right after the query has arrived, perform find, send the results back and finally close the large database to release resources. The same for storing events into it or even better, some kind of append function which will only append records and then close database file without the need to load and parse, prepare indexes and so on.

[kaizhu256]

@zevero i learned from experience (and confirmed from nedb's author) that multiple nedb instances (running in separate processes) on a single file will corrupt that file.

in your password example, if u have a unique constraint for "username" or "email", it will get violated by race-conditions from the multiple nedb instances, @ which point nedb will refuse to load the file and crash

[JamesMGreene]

See PR #414.