We are using
settings.defaultTransformOptions = { useBuffer: true };
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 = indexeddbsource
source.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 @
const changes = buffer.stopTrackingChanges();
Versions
"@orbit/indexeddb": "0.17.2",
"@orbit/indexeddb-bucket": "0.17.0",
"@orbit/jsonapi": "0.17.1",
"@orbit/records": "0.17.0",
"@orbit/serializers": "0.17.0",
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
AsyncCacheIntegrityProcessorprocessor 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