Skip to content
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 EntityCache as replacement for DepTrackingCache and ObjectCache. #5197

Merged
merged 9 commits into from Aug 21, 2019

Conversation

@benjamn
Copy link
Member

@benjamn benjamn commented Aug 16, 2019

The new EntityCache is like the old DepTrackingCache in that it can track dependencies to enable caching repeated reads (#3394). However, the EntityCache also incorporates the OptimisticCacheLayer logic (#4319) that was previously implemented in inMemoryCache.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 EntityCache also removes the need for both the ObjectCache and the MapCache, which were alternate cache implementations one could theoretically use instead of the default DepTrackingCache.

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.

@benjamn benjamn added this to the Release 3.0 milestone Aug 16, 2019
@benjamn benjamn self-assigned this Aug 16, 2019
book: {
__typename: 'Book',
isbn: '9781451673319',
title: 'Fahrenheit 451',
Copy link
Member Author

@benjamn benjamn Aug 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extremely trivial fun fact: this completely authentic ISBN number for Fahrenheit 451 contains 451 as adjacent digits. 📚🔥

Loading

@benjamn benjamn requested review from hwillson and jbaxleyiii Aug 16, 2019
Copy link
Member

@hwillson hwillson left a comment

Looks great @benjamn! 👍

Loading

@benjamn benjamn merged commit 33d9dcc into release-3.0 Aug 21, 2019
7 checks passed
Loading
@benjamn
Copy link
Member Author

@benjamn benjamn commented Aug 21, 2019

Merging this so that @hwillson can go ahead and work on restructuring the repo starting from the release-3.0 branch.

Loading

@benjamn benjamn deleted the enable-result-caching-for-optimistic-reads branch Aug 21, 2019
benjamn added a commit that referenced this issue 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 issue 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 join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants