You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
as otherwise the performance of indexeddb bulk operations is very very slow.
Unfortunately, with the latest version, we see that the store for keeping track of rels is not touched at all when removing a record.
Example:
// source = indexeddbsourcesource.push([source.transformBuilder.removeRecord({id: '123',type: 'test'})]);// Result in indexeddb with `useBuffer: true`// 1. Record '123' is removed from store `test`// 2. All relationships in store `__inverseRels__` of record '123' are still there// Result in indexeddb with `useBuffer: false`// 1. Record '123' is removed from store `test`// 2. All relationships in store `__inverseRels__` of record '123' are removed
After some digging, I think the AsyncCacheIntegrityProcessor processor creates the transforms that clean up the __inverseRels__ store with useBuffer: false.
With useBuffer: true, it seems to be the job of SyncCacheIntegrityProcessor, but somehow it fails to return the changeset to remove the inverse rels @
We are using
as otherwise the performance of indexeddb bulk operations is very very slow.
Unfortunately, with the latest version, we see that the store for keeping track of rels is not touched at all when removing a record.
Example:
After some digging, I think the
AsyncCacheIntegrityProcessor
processor creates the transforms that clean up the__inverseRels__
store withuseBuffer: false
.With
useBuffer: true
, it seems to be the job ofSyncCacheIntegrityProcessor
, but somehow it fails to return the changeset to remove the inverse rels @Versions
The text was updated successfully, but these errors were encountered: