search

bajankristof / nedb-promises

A dead-simple promise wrapper for nedb.
MIT License
298 stars 45 forks source link

. #54

Closed ArchI3Chris closed 2 years ago

ArchI3Chris commented 2 years ago

.

bajankristof commented 2 years ago

Hi,

What you are experiencing here is on purpose. This kind of behaviour is called atomicity for databases. If an operation is atomic it guarantees the success or failure of the operation as a whole, meaning that if (like in your example) just one part of the operation fails the whole operation fails with it and everything remains the same on the storage level. This can be painful in some situations but amazing in others.

Just as an example when this is useful: You store images and compression tasks in a datastore, the compression task is picked up by the app and the app compresses the image that is assigned to it to a desired size or format. When a user adds a new image you need to insert both an image and a compression task into the database. Now if it weren't for atomicity something could go wrong and you could end up with an image that is never going to be compressed because the compression task couldn't be inserted or you could end up with a compression task with an image assigned that doesn't exist because the image couldn't be inserted. With atomicity you (your app) is guaranteed to only succeed with the insert if both of the documents are successfully inserted. (I hope this explanation makes sense.)

As to what can be done here: What I can think of off the top of my head is upserts in combination with returnUpdatedDocs. With that you could reduce the number of operations to N (N being the number of documents that you are trying to insert). See the docs here.

I hope I was able to help you, have a nice day!

ArchI3Chris commented 2 years ago

.

bajankristof commented 2 years ago

First off, I'll let the honestly quite arrogant tone slide and try to shed some light on some stuff:

  1. I did not create nedb so I don't know the reasoning behind the development, it could be out of boredom. I'm just the humble maintainer of a promise wrapper for the library.
  2. Of course nedb is not meant to be used as database for web development projects, there are much better solutions for that. You can use nedb as a backup to store data in case the actual database is not available, or when working with electron for example where you might need to store (obviously non-sensitive) data on the clients computer.
  3. nedb does persist data on the disk so I don't see the whole reasoning behind your in-memory rant.
  4. Atomicity means exactly what I said it means in the example: "database will either see all of the changes or none of the changes".
  5. As to what advantages nedb offers compared to plain JSON files is quite simple. It uses binary search trees to optimize queries to the database so you don't need to, it implements indexes so you don't need to. Otherwise you would be just going over an array of objects over and over again to retrieve the data you need.
  6. As for growing myself, I'm constantly trying to improve. Are you? Maybe you should start with the tone you interact with people.