Make searches chainable using and/or

[avit]

I'd like to add a feature for merging searches like search_parents.or(search_children). With #412 it becomes doable by setting up a shared context to handle the join aliases before building the search conditions:

shared_context = Ransack::Context.for(Person)
search_parents = Person.search({parent_name_eq: "A"}, context: shared_context)
search_children = Person.search({children_name_eq: "B"}, context: shared_context)
shared_conditions = [search_parents, search_children].map { |search|
  Ransack::Visitor.new.accept(search.base)
}.reduce(&:or)

Person.joins(shared_context.join_sources).where(shared_conditions)

Currently the context needs to be passed around before initializing searches, because the initializer automatically calls build to populate the condition tree. This would need to change to evaluate lazily.

[art-solopov]

I unfortunately cannot use this at all. Ransack::Visitor.new.accept just returns nil.

[imtiazwazir]

+1

[Lance-Foley]

+1

[kluzny]

I was also getting Ransack::Visitor.new.accept(search.base) as nil when the search fields were empty, as would be for a default empty search. Since there is no Arel associated with these nil-like searches joining via AND/OR was not possible.

Something like:

parent_filter = {}
parent_filter[:parent_name_eq] = parent_params[:name] if parent_params[:name].present?
search_parents = Person.search(parent_params, context: shared_context)

In this case, if no name param was provided, the search hash would be empty, thus the Ransack::Visitor.new.accept would be nil, and throw an error on the call to :or'

I solved this with a bit of a hack, I force at least some trivial condition to exist so there is always some Arel generated

# in my schema, id is always present
parent_filter = { id_is_not_null }

This is reminiscent of the old sql 1=1 AND conditional. I haven't explored this idea much further, but surely there is some trivial or unit like Arel value that can always be and/or chained to something as opposed to nil. Although perhaps the simplest solution is just to not generate the search/context at all for empty queries.