Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implement IndexedDB LRU Reference Delegate, add LRU tests #1224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement IndexedDB LRU Reference Delegate, add LRU tests #1224
Changes from 3 commits
eab8740
6818502
d37c2c4
11cad0d
3114ce7
5718c24
baa9fa8
ed3c84d
9d68610
cba7bf7
f88817a
a79a941
be943c5
16eaaca
e25162c
279e14a
34f7967
801694c
34f62fb
3b748b1
11b0baf
366418e
fcbb366
c922dce
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These sentinel keys are target_document entries, which are normally managed by the QueryCache, right? Can we preserve that (have a method on QueryCache to delete them)? I'm not excited about having multiple classes interacting with the same underlying IndexedDb stores. Seems like breaking that encapsulation increases the opportunity for bugs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking about this a bit, I think I would actually go the other way. Currently, I have
forEachOrphanedDocument
implemented inIndexedDbQueryCache
, which is the only place the query cache interacts with instances ofSentinelRow
. I think it would be better to confine access to theSentinelRow
in theReferenceDelegate
, and let the query cache only worry about actual targets.That way, the query cache almost* doesn't have to know anything about the sentinel rows, and only the reference delegate has to know about them being stored alongside normal target-document rows.
*: the query cache currently has a
containsKey
implementation that needs to disregard sentinel rows, although it doesn't need to know about the type, just that thetargetId
is0
. Once the lru stuff is fully ported, this method is only used in tests, and could be moved to a helper in test code.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I should also note that the ports already diverge a bit especially around this area, since each platform has a different way of interacting with on-disk data.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still have mixed feelings about this. I liked having individual object stores owned by a specific component. That way it's easy for me to consider all of the interactions within that store together. I'm curious why we didn't just have a separate store for the sentinel rows, but I assume there was a good reason and that ship has probably sailed anyway.
So I'm fine with this as-is, except per my other comments I think we should avoid
sentinelKeyStore()
since it suggests there is a separate store, which is not the case.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason sentinel rows are interleaved with target-document rows is efficiency. The current algorithm for identifying orphaned documents is a scan. Using a separate store would require scanning that store, and then for each row, doing a lookup in the target-document store. FWIW, we tried this in sqlite on Android by adding a sequence number column to each remote document. It was faster to add a nullable column to the target-document many-to-many table that only had values where
targetId == 0
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems confusing to have two different names for the same store depending on how it's used. I'm also concerned that we seem to be describing schema outside of indexeddb_schema.ts. That should be the authoritative description of our entire persistence schema. This also seems to be a deviation from Android.
Is there another way to go about this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've removed the only reference the query cache had to sequence numbers being available on target-document entries. I think it would be nice to keep this knowledge separate: the query cache can deal in target-document associations, and the reference delegate can deal with the sentinel rows. This is now accomplished via
SentinelRow
being confined to the reference delegate. We could potentially have two different views of the schema defined inindexeddb_schema.ts
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel pretty strongly that indexeddb_schema.ts should continue to be a complete and authoritative description of our schema. So
sequenceNumber
should be included there.Having sentinelKey() and sentinelRow() helpers here seems useful and good (and consistent with Android), but sentinelKeyStore() strongly communicates to me that there's a separate object store for these sentinel rows, which is not what we've actually implemented. I'd be fine with moving them to a separate store, but if they're in the "targetDocuments" object store, calling it something else is confusing to me.
So can we drop SentinelRow and sentinelKeyStore() from here, and just define "sequenceNumber" as part of the DbTargetDocument schema?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My main concern is that I don't want the query cache to have access to the sequence number. It's not present for any rows that the query cache would be dealing with. I've removed
SentinelRow
andsentinelKeyStore()
though. I've added an assert to the constructor forDbTargetDocument
.