Implement EntityCache as replacement for DepTrackingCache and ObjectCache. #5197
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This could be a breaking change, since the exports of objectCache.ts were previously re-exported by index.ts, whereas now we re-export the exports of entityCache.ts.
benjamn
commented
Aug 16, 2019
| book: { | ||
| __typename: 'Book', | ||
| isbn: '9781451673319', | ||
| title: 'Fahrenheit 451', |
There was a problem hiding this comment.
Extremely trivial fun fact: this completely authentic ISBN number for Fahrenheit 451 contains 451 as adjacent digits. 📚🔥
hwillson
approved these changes
Aug 19, 2019
|
Merging this so that @hwillson can go ahead and work on restructuring the repo starting from the |
benjamn
added a commit
that referenced
this pull request
Dec 3, 2019
The result caching system introduced by #3394 gained the ability to cache optimistic results (rather than just non-optimistic results) in #5197, but since then has suffered from unnecessary cache key diversity during optimistic updates, because every EntityStore.Layer object (corresponding to a single optimistic update) counts as a distinct cache key, which prevents cached results from being reused if they were originally read from a different Layer object. This commit introduces the concept of a CacheGroup, store.group, which manages dependency tracking and also serves as a source of keys for the result caching system. While the Root object has its own CacheGroup, Layer objects share a CacheGroup object, which is the key to limiting diversity of cache keys when more than one optimistic update is pending. This separation allows the InMemoryCache to enjoy the full benefits of result caching for both optimistic (Layer) and non-optimistic (Root) data, separately.
benjamn
added a commit
that referenced
this pull request
Dec 3, 2019
The result caching system introduced by #3394 gained the ability to cache optimistic results (rather than just non-optimistic results) in #5197, but since then has suffered from unnecessary cache key diversity during optimistic updates, because every EntityStore.Layer object (corresponding to a single optimistic update) counts as a distinct cache key, which prevents cached results from being reused if they were originally read from a different Layer object. This commit introduces the concept of a CacheGroup, store.group, which manages dependency tracking and also serves as a source of keys for the result caching system. While the Root object has its own CacheGroup, Layer objects share a CacheGroup object, which is the key to limiting diversity of cache keys when more than one optimistic update is pending. This separation allows the InMemoryCache to enjoy the full benefits of result caching for both optimistic (Layer) and non-optimistic (Root) data, separately.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
The new
EntityCacheis like the oldDepTrackingCachein that it can track dependencies to enable caching repeated reads (#3394). However, theEntityCachealso incorporates theOptimisticCacheLayerlogic (#4319) that was previously implemented ininMemoryCache.ts, thereby providing the same result caching benefits for optimistic cache reads, while preserving the possibility of reading non-optimistic data while optimistic data are still active.The
EntityCachealso removes the need for both theObjectCacheand theMapCache, which were alternate cache implementations one could theoretically use instead of the defaultDepTrackingCache.By moving optimistic caching logic into the same area of the code that handles non-optimistic caching, this PR sets the stage for garbage collection (see also #4681), since automatic garbage collection needs to take into account the full contents of the cache, including optimistic data.