Previously, we were re-inserting all items regardless of whether they
were changed or not. This raised a lot of issues, not to mention
unnecessary load on our servers because after each migration
all the data is re-synced. Since migration takes place independently on
each device, this multiplies exponentially.
Hopefully after this update, this will only happen much more granually.
this is better design wise as we won't have to keep checking if the
indices have been migrated or not. We'll just check the database version
and do the appropriate migrations based on that.
This should not affect the items or their server representation.
This change is necessary to allow multiple items with same id
that live in different collections.
For example, shortcuts have the same id as the inner reference they
point to. This was not possible before and would cause an overwrite
of the original value.
this was not exactly a bug but it can cause a lot of unintended
behaviour. Previously, you'd have to manually specify which version the
item migration should jump to. This was buggy and poorly designed.
This change makes the item iterate over all the db migrations one by one
automatically.
For example:
An item at version 5.2 will go through:
- 5.3
- 5.4
- and so on
This is a BREAKING change in the core & will require updating the
clients. The way it works is instead of keeping noteIds of all the
notes in the topic, it keeps an in-memory cache. This in-memory
cache `topicReferences` lives in the notes collection & decouples
notes from notebooks/topics. This also simplifies all the different
actions where references would persist after the note was deleted.
Since the note acts as the source of truth for where it currently is,
there is nothing else to do except rebuild the `topicReferences`
cache.
