-
Notifications
You must be signed in to change notification settings - Fork 30
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
@connection directive support #289
Comments
Ah, hmm, this cache doesn't have explicit support for I'm curious: what keys end up being written to when you load the first query as opposed to the second? Try turning on verbose mode, which'll log out snapshots for each write and lists of ids that have changed; might help us narrow it down |
@neviri picked this out from the logs, it looks like they are being stored in two different locations Any action I can take to help? |
I think at this point
We determine if the field is a connection directive? and change the key based on that |
Yeah, or potentially earlier when parsing the query ( |
Re:
We're unfortunately not going to have much bandwidth to dig into this much for the next couple weeks—if you want to take a stab at an implementation, that'd be a huge help! It might also be worth checking out how inmemory handles the |
I'll take a stab when I get the opportunity, we should avoid merging there isn't enough information to do so, overwrite the previous result with the new which will keep inserts fast, it's the responsibility of the application developer — when fetching more) — to maintain this state, thanks for the research into in-memory cache's implementation |
Hi guys, I'm not sure if this is an issue with my application but it seems like the @connection directive isn't working as expected
the two places I use it are as such, (code stripped for brevity)
If I remove the cursor from the second query it is working fine, any ideas?
The text was updated successfully, but these errors were encountered: