You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Request for support. Note: Please try to avoid submitting issues for support requests. Use Gitter instead.
Checklist before submitting:
I've searched for an existing issue.
I've asked my question on Gitter and have not received a satisfactory answer.
I've included a complete bug report template. This step helps us and allows us to see the bug without trying to reproduce the problem from your description. It helps you because you will frequently detect if it's a problem specific to your project.
The feature I'm asking for is compliant with the JSON:API spec.
Description
Current:
In version 0.9 and earlier JR relied on the Rails eager loading using the ActiveRecord includes. In a typical Rails app this feature works great, but we ran into a lot of edge cases and performance compromises when auto generating the queries JR needs for complex requests - especially ones with complex includes. In addition the complexity grew with caching.
With this approach we recommended that related resources be controlled using relation_name on the relationship. This relation was used in the includes and provides a way to control the related resources.
With version 0.10 the approach was changed and we no longer use rails eager loading. The relation_name on the relationship can still be used for relationship filtering.
There is also the option of using the apply_join callable on the relationship.
Both of the above options however require explicitly wiring up the appropriate code on each relationship.
Proposed change:
When joining related records in ActiveRelationResource.apply_join we have to opportunity to use ActiveRecord's merge method to apply the related resource's records logic. The implication of this is all accesses to a Resource will use the same records applied logic whether coming to the resource as the primary resource in a request, as an included resource, or through the related link of the parent resource.
I believe this one change should drastically simplify resource authentication and opens up some further opportunities to further simplify most resources.
The text was updated successfully, but these errors were encountered:
This issue is a (choose one):
Checklist before submitting:
Description
Current:
In version 0.9 and earlier JR relied on the Rails eager loading using the ActiveRecord
includes
. In a typical Rails app this feature works great, but we ran into a lot of edge cases and performance compromises when auto generating the queries JR needs for complex requests - especially ones with complex includes. In addition the complexity grew with caching.With this approach we recommended that related resources be controlled using
relation_name
on the relationship. This relation was used in the includes and provides a way to control the related resources.With version 0.10 the approach was changed and we no longer use rails eager loading. The
relation_name
on the relationship can still be used for relationship filtering.There is also the option of using the
apply_join
callable on the relationship.Both of the above options however require explicitly wiring up the appropriate code on each relationship.
Proposed change:
When joining related records in
ActiveRelationResource.apply_join
we have to opportunity to use ActiveRecord'smerge
method to apply the related resource'srecords
logic. The implication of this is all accesses to a Resource will use the samerecords
applied logic whether coming to the resource as the primary resource in a request, as an included resource, or through therelated
link of the parent resource.I believe this one change should drastically simplify resource authentication and opens up some further opportunities to further simplify most resources.
The text was updated successfully, but these errors were encountered: