would apprecaite migration guide/outline from louischatriot's 1.8.0; thanks

[archywillhe]

hi; I'm the maintainer of Insominum.

This looks really good && I'm planning to migrate to this fork of nedb (from the louischatriot's 1.8.0);

will appreciate any guide/outline; thanks!

[archywillhe]

(reading the changelog; 2.0 looks like a good start for us. would 3.0 has breaking changes or anything to keep in mind? )

[tex0l]

Hi! Version 2.0.0 is just a refreshing of the 1.8.x version, it is breaking in the sense that it uses more recent ES2015 syntax, and updated underscore, but otherwise is non breaking.

The version 3.0.0 is a major rewrite which removes unnecessary dependencies by switching most of the async work from a deprecated library (async) to native Promises, and which changes internal signatures, exposes a new Promise-based interface, but keeps the old callback interface available.

If you don't use internal functions of NeDB, the only changes that can be breaking (at least that's how it was designed) are:

• The corruptionAlertThreshold now doesn't take into account empty lines, and the error message is slightly changed.
• The Datastore#update's callback has its signature slightly changed. The upsert flag is always defined either at true or false but not null nor undefined, and affectedDocuments is null when none is given rather than undefined (except when there is an error of course).

Version 3.1.0 is non breaking compared to 3.0.0, implements a feature to avoid testing serializationHooks, which is disabled by default.

Version 4.0.0 implements compound indexes which prevents using commas in indexed field names, which is technically a breaking change, even if there's a very high probability you are not affected.

Subsequent patches are non-breaking.

TL;DR: if you don't commas in indexed filed names, and if you use the upsert flag and affectedDocuments arguments in the callback of Datastore#update, you should be able to update to the latest version with no problem. If you do, the changes should be marginal. If you use internal functions however, such as the ones described in 3.0.0 changelog, I recommend modifying your use of the internals to the the signature.

[archywillhe]

aww thanks for the detailed breakdown! this is amazing!