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'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.
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_nameon 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_nameon the relationship can still be used for relationship filtering.There is also the option of using the
apply_joincallable 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_joinwe have to opportunity to use ActiveRecord'smergemethod to apply the related resource'srecordslogic. The implication of this is all accesses to a Resource will use the samerecordsapplied logic whether coming to the resource as the primary resource in a request, as an included resource, or through therelatedlink 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.