Weird behaviour - after deleting entire DB about nedb HOT 9 CLOSED

This seems very much like a bug where the executor would stop executing command if one command (insert/find/update/remove) had been called without a callback (even though you should be able to do that).

My guess is that you don't give a callback to the remove function and so after that no command gets treated until your page is reloaded and the database created.

To test this you could simply do two inserts at once without a callback, in a new db (i.e. no datafile). If there is only one line that means it is indeed the bug I described. In that case, it was fixed some time ago (v0.7.13 I think) so simply using NeDB's latest version should do the trick. Please tell me if that's the case.

from nedb.

I'm 99% sure I'm using the latest (synced today) nedb - however the delete doesn't have (or need) a callback, I'll see what happen if I insert one (I'll do a random db.find())

from nedb.

Yeah, putting something into the callback for the delete seems to solve this - this is with the latest npm release too.

from nedb.

In that case this is clearly not the expected behaviour. Cold you give me a reproducible test case so I can solve this?

Le 11 juil. 2013 à 20:28, shrewdlogarithm [email protected] a écrit :

Yeah, putting something into the callback for the delete seems to solve this - this is with the latest npm release too.

—
Reply to this email directly or view it on GitHub.

from nedb.

It's not easy to make a test case from a node webkit app - and I've changed the way this one works which means it doesn't (easily) reproduce the error any longer (beyond just adding a callback to the delete).

I cannot make a standalone node.js app which reproduces this yet either - I suspect it's not just a straight 'delete everything with no callback' - I think it may be other actions carried out (perhaps also without callbacks) which are impacting on the issue.

I'll have to get back to you if/when I re-run into this one

from nedb.

I can't seem to find a way to reproduce this and I'm not actually sure it's a bug in nedb. Could you just send me your entire script code so that I have a chance to understand what's going on?

from nedb.

My entire code is over 3000 lines over 24 separate files (all of which access the DB in some way) - even the core DB stuff is 400+lines...

What I've discovered is that I can rollback my project to any point-in-time (Webstorm is amazing) so later, I'll backup and do just that - and I'll edit-in a complete trace of all DB activity - which I can then recreate as a testcase in plain node.js

But now I must go into the outside world for it is time to eat!

from nedb.

OK, local history revealed that I updated to the latest NEDB after I first ran into this error (but I was working on something else at the time - this is the value of labelling your source changes!!) - which means my adding the callback didn't fix it - just upgrading NEDB did.

Webstorm is really amazing tho - without it I'd still be manually digging files out of the backup archive!

We can close this as being no longer an issue I think...

from nedb.

Great :)

from nedb.