Remove empty key value pairs when using advanced search hash

[gdott9]

Description

When a condition in the advanced search hash has an empty value, the condition is not removed so the "LEFT OUTER JOIN" is added to the SQL query without a "WHERE" clause.

Problem

The behavior is not the same when using a simple condition hash (example: {children_name_eq: ''}) versus using an advanced search hash (example: {c: {'0' => {a: ['children_name'], p: 'eq', v: ['']}}}).

The first example results in the following query :

SELECT "people".* FROM "people" ORDER BY "people"."id" DESC

The second example results in the following query :

SELECT "people".* FROM "people" LEFT OUTER JOIN "people" "children_people" ON "children_people"."parent_id" = "people"."id" ORDER BY "people"."id" DESC

Proposed solution

I added code to remove conditions with a blank value in the same way it is done with the simple condition.
Do you see a better way to handle this ?

[scarroll32]

Note

Comment from Claude (Claude Code), acting on behalf of @scarroll32.

Thanks @gdott9 — good catch, and the comparison between the shorthand and c: forms in your description made it easy to confirm. Picked up and finished in #1687, with you as co-author.

Three things needed changing before it could land, one of them significant:

The Hash form of v: was being dropped unconditionally. The guard reads

value[:v].all? { |_, i| value[:value].blank? && value[:value] != false }

but value there is the enclosing condition hash ({a:, p:, v:}), so value[:value] is always nil — always blank, never false. The block ignores i entirely. I ran it against your branch to be sure:

Person.ransack(c: { '0' => { a: ['name'], p: 'eq', v: { '0' => { value: 'Ernie' } } } }).result.to_sql
# => SELECT "people".* FROM "people" ORDER BY "people"."id" DESC

The condition disappears and the search returns everything. That's a worse outcome than the original bug, so #1687 unwraps the value from either the bare or { value: ... } form before testing it.

String keys. params hasn't been through with_indifferent_access yet at that point in initialize, so params.key?(:c) misses the "c" that arrives from an HTTP query string — which is how most people reach this API.

The blank test is now shared between the top-level filter and the c: filter. Your version re-implemented it, which happened to drop the !i.nil? clause added in #1657 and would have regressed name_in: [nil].

Also fixed the two Layout/SpaceAfterComma offences that were failing the build check here.

Your spec is kept, with three more covering the cases above. Closing in favour of #1687 — thanks again.