-
Notifications
You must be signed in to change notification settings - Fork 653
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
Asynchronous caching and subsequent reads #5852
Comments
There is nothing like this.
Nothing like this at the moment.
We could swap the order of the two lines here. Meaning you could rely on the |
Removing that guarantee is definitely not ideal, and I imagine it will break a lot of current code that's working under this guarantee. I am also not sure if swapping the order of the lines will actually work: when asynchronous caching is enabled, I see that we are using |
I have submitted a proposal for this in PR #5877, but there is a caveat when you use |
Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo Kotlin usage and allow us to serve you better. |
Question
We use asynchronous caching for almost all our operations. Are the cache writes vs subsequent reads guaranteed to be consistent or locked when using asynchronous caching?
So for example:
client.query(foo)
, we got the response, but it's still writing to cacheclient.watch(foo)
Is this second operation guaranteed to hit the cache (assuming it's the exact same operation)? Or can it miss the cache if the previous operation is not done writing to it? Or in other words, are cache reads locked against any ongoing writes?
And along similar lines, when using asynchronous caching, is there any way to get a signal that write to cache has completed? For example, if we use
.toFlow()
, we can get oneApolloResponse<D>
followed by a completion event when it's done writing -- does that seem like something that can be done?Thank you!
The text was updated successfully, but these errors were encountered: