16.0.0

The release 16.0.0 is used for major refactorings. We did not change that much, mostly renaming things and fixing confusing implementation details.

Data stored in the previous version 15 is compatible with the code of the new version 16 for most RxStorage implementation. So migration will be easy. Only the following RxStorage implementations are required to migrate the data itself with the storage migration plugin:

• SQLite RxStorage
• NodeFilesystem RxStorage
• OPFS RxStorage

Breaking Changes

• CHANGE RxServer is no longer in beta mode.
• CHANGE Fulltext Search is no longer in beta mode.
• CHANGE Custom Reactivity is no longer in beta mode.
• CHANGE initialCheckpoint in replications is no longer in beta mode.
• CHANGE RxState is no longer in beta mode.
• CHANGE MemoryMapped RxStorage is no longer in beta mode.
• CHANGE rename randomCouchString() to randomToken()
• FIX (GraphQL replication) datapath must be equivalent for pull and push #6019
• REMOVE fallback to the ohash package when crypto.subtle does not exist. All modern runtimes (also react-native) now support crypto.subtle, so we do not need that fallback anymore.

Removed deprecated LokiJS RxStorage

The LokiJS RxStorage was deprecated because LokiJS itself is no longer maintained. Therefore it will be removed completely. If you still need that, you can fork the code of it and publish it in an own package and link to it from the third party plugins page.

Renamed .destroy() to .close()

Destroy was adapted from PouchDB, but people often think this deletes the written data. close is a better name for that functionality.

• Also renamed similar functions/attributes:
  • .destroy() to .close()
  • .onDestroy() to .onClose()
  • postDestroyRxCollection to postCloseRxCollection
  • preDestroyRxDatabase to preCloseRxDatabase

ignoreDuplicate: true on createRxDatabase() must only be allowed in dev-mode.

The ignoreDuplicate flag is only useful for tests and should never be used in production. We now throw an error if it is set to true in non-dev-mode.

When dev-mode is enabled, a schema validator must be used.

Many reported issues come from people storing data that is not valid to their schema. To fix this, in dev-mode it is now required that at least one schema validator is used.

Removed the memory-synced storage

The memory-synced RxStorage was removed in RxDB version 16. Please use the memory-mapped storage instead which has better trade-offs and is easier to configure.

Split conflict handler functionality into isEqual() and resolve().

Because the handler is used in so many places it becomes confusing to write a proper conflict handler. Also having a handler that requires user interaction is only possible by hackingly using the context param. By splitting the functionalities it is easier to learn where the handlers are used and how to define them properly.

Full rewrite of the OPFS and Filesystem-Node RxStorages

The OPFS and Filesystem-Node RxStorage had problems with storing emojis and other special characters inside of indexed fields. I completely rewrote them and improved performance especially on initial load when a lot of data is stored already and when doing many small writes/reads at the same time on in series.

Internal Changes

• CHANGE (internal) migration-storage plugin: Remove catch from cleanup
• CHANGE (internal) rename RX_PIPELINE_CHECKPOINT_CONTEXT to rx-pipeline-checkpoint
• CHANGE (internal) remove conflictResultionTasks() and resolveConflictResultionTask() from the RxStorage interface.
• REMOVED (internal) do not check for duplicate event bulks, all RxStorage implementations must guarantee to not emit the same events twice.
• REFACTOR (internal) Only use event-bulks internally and only transform to single emitted events if actually someone has subscribed to the eventstream.

Bugfixes

• Having a lot of documents pulled in the replication could in some cases slow down the database initialization because upstreamInitialSync() did not set a checkpoint and each time checked all documents if they are equal to the master.
• If the handler of a RxPipeline throws an error, block the whole pipeline and emit the error to the outside.
• Throw error when dexie.js RxStorage is used with optional index fields #6643.
• Fix IndexedDB bug: Some people had problems with the IndexedDB RxStorage that opened up collections very slowly. If you had this problem, please try out this new version.
• Add check to ensure remote instances are build with the same RxDB version. This is to ensure if you update RxDB and forget to rebuild your workers, it will throw instead of causing strange problems.
• When the pulled documents in the replication do not match the schema, do not update the checkpoint.
• When the pushed document conflict results in the replication do not match the schema, do not update the checkpoint.

Other

• Added more performance tests
• The amount of collections in the open source version has been limited to 16.
• Moved RxQuery checks into dev-mode.
• RxQuery.remove() now internally does a bulk operation for better performance.
• Lazily process bulkWrite() results for less CPU usage.
• Only run interval cleanup on the storage of a collection if there actually have been writes to it.
• Schema validation errors (code: 422) now include the RxJsonSchema for easier debugging.
• Added an interval to prevent browser tab hibernation while a replication is running.

You can help!

There are many things that can be done by you to improve RxDB:

• Check the BACKLOG for features that would be great to have.
• Check the breaking backlog for breaking changes that must be implemented in the future but where I did not have the time yet.
• Check the todos in the code. There are many small improvements that can be done for performance and build size.
• Review the code and add tests. I am only a single human with a laptop. My code is not perfect and much small improvements can be done when people review the code and help me to clarify undefined behaviors.
• Update the example projects some of them are outdated and need updates.

LinkedIn

Stay connected with the latest updates and network with professionals in the RxDB community by following RxDB's official LinkedIn page!