-
Notifications
You must be signed in to change notification settings - Fork 35
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
performance issues with linkage(always: true) #106
Comments
The idea here is that the serialization layer is not responsible for the way you fetch your data. Note that if you are using |
True, Thanks for the quick feedback! However, that is not the issue I am having (though I do need to do that as well). I think I did a poor job of explaining. Let me try again. If I have
This gem loads too much data in my opinion. When I go a get on an Further more I expect that if |
@spencerroan It's been a while, but any more developments on this issue? I'm using graphiti (which uses jsonapi-serializable) and am running into an n+1 when including linkages. I'm looking at your monkey patch, but can't find the place where it's patching. Do you have to call anything extra when defining your relationships? |
Drop the above code somewhere that will get loaded.
Good Luck! |
In our serializers we make liberal use of linkage(always: true). This fully renders the relationship including any calls out to new linkages. This is a performance issue and generates n+1 queries for objects we were not planning on loading. I'm going to build something that looks up what the include tree should be based on what we always include and what is asked for.
For instance:
When rendering a Bar without including quxes, I don't expect the
has_many quxes
to be serialized.In the short term I've made this monkey patch to avoid loading extra layers of relationships:
I'll explore ways of not monkey patching like creating a sister to
linkage()
that does more of what I need performance wise.This seems related to:
#91
#100
#49
I guess an additional issue I have is that the related object is loaded even on a belongs_to. I'd assume the reflection of the relationship could generate
id
andtype
without loading the object, but it does make for more conditional/brittle code.The text was updated successfully, but these errors were encountered: