module AmsLazyRelationships
There is a general problem inside AMS related to custom association finder combined with `include_data` setting:
class BlogPostSerializer < BaseSerializer belongs_to :category do include_data :if_sideloaded object.categories.last end end
The problem is that `belongs_to` block will be fully evaluated each time for each object, and only after that AMS is able to take into account `include_data` mode - github.com/rails-api/active_model_serializers/blob/v0.10.10/lib/active_model/serializer/reflection.rb#L162-L163
def value(serializer, include_slice) # ... block_value = instance_exec(serializer, &block) if block return unless include_data?(include_slice) # ... end
That causing redundant (and so huge potentially!) SQL queries and AR objects allocation when `include_data` appears to be `false` but `belongs_to` block defines instant (not a kind of AR::Relation) custom association finder.
Described problem is a very specific use case for pure AMS applications. The bad news is that `ams_lazy_relationships` always utilizes the association block - github.com/Bajena/ams_lazy_relationships/blob/v0.2.0/lib/ams_lazy_relationships/core/relationship_wrapper_methods.rb#L32-L36
def define_lazy_association(type, name, options, block)
#... block ||= lambda do |serializer| serializer.public_send("lazy_#{name}") end public_send(type, name.to_sym, real_relationship_options, &block) #...
end
This way we break `include_data` optimizations for the host application.
In order to overcome that we are forced to monkey-patch `AmsLazyRelationships::Extensions::Reflection#value` method and make it to be ready for Proc returned by association block. This way we will use a kind of
block ||= lambda do |serializer| -> { serializer.public_send("lazy_#{name}") } end
as association block, then AMS will evaluate it, get the value of `include_data` setting, make a decision do we need to continue with that association, if so - will finally evaluate the proc with lazy relationship inside it.
Constants
- VERSION