Avoid duplicate clauses when using #or

[MaxLap]

Attempt number 2 for this change. A refactor of WhereClause by @sgrif made this change a lot simpler. Initial proposal at #29805.

Right now, when using #or, nothing is done to try to avoid duplicated conditions. As a result, query length increases at an exponential rate. This makes it really hard to parse for humans, making debugging / understanding the query log really hard.

To show the scale of the problem:

class Project
    scope :big, -> { where(big1: true).or(where(big2: true)) }
    scope :important, -> { where(important1: true).or(where(important2: true)) }
    scope :ongoing, -> { where(ongoing1: true).or(where(ongoing2: true)) }
end

Project.big # 2 conditions
#=> SELECT...WHERE ("projects"."big1" = ? OR "projects"."big2" = ?) 
Project.big.important # 6 conditions
#=> SELECT...WHERE (("projects"."big1" = ? OR "projects"."big2" = ?) AND "projects"."important1" = ? OR ("projects"."big1" = ? OR "projects"."big2" = ?) AND "projects"."important2" = ?)
Project.big.important.ongoing # 14 conditions
#=> To long to show
# Then 30 conditions
# Then 62
# Then 126 conditions, for using #or 6 times. This should be 12!

# After this fix, it is correctly 2, 4, 6, 8, 10, ... conditions.

[rails-bot]

Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @pixeltrix (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

This repository is being automatically checked for code quality issues using Code Climate. You can see results for this analysis in the PR status below. Newly introduced issues should be fixed before a Pull Request is considered ready to review.

Please see the contribution instructions for more information.

[lugray]

Is this addtional manipulation really necessary for the test?

[lugray]

The redefinition makes this harder to understand. Why not instead:

common = wcs[0]

actual = (common + wcs[1]).or(common + wcs[2])
expected = common + wcs[1].or(wcs[2])

[sgrif]

I'd prefer to avoid postfix conditionals (and early returns for that matter) if possible. How about this instead?

if left.empty? || right.empty?
  common
else
  or_clause = WhereClause.new(
    [left.ast.or(right.ast)],
  )
  common + or_clause
end

[sgrif]

This sort of thing makes this test really difficult to read. How about something like this?

a = WhereClause.new(
  [table["id"].eq(bind_param(1)), table["name"].eq(bind_param("Sean"))],
)
b = WhereClause.new(
  [table["id"].eq(bind_param(1)) ,table["hair_color"].eq(bind_param("black"))],
)
common = WhereClause.new(
  [table["id"].eq(bind_param(1))],
)
or_clause = WhereClause.new(
  [table["name"].eq(bind_param("Sean")).or(table["hair_color"].eq(bind_param("black")))],
)

assert_equal common + or_clause, a.or(b)

[MaxLap]

Just tried, that doesn't work because WhereClause#or isn't call for both sides, and WhereClause#or always adds a And node around the predicates, even if there only one.

I'll tweak the test.

[sgrif]

I also find this really hard to read. Can we either just test this once, or just write out the actual conditions that we're testing?

[MaxLap]

Personally, I thought that using variables and then doing + to concatenate conditions together helped with readability. But i'll change it to be more basic and will split the tests into smaller ones.

[MaxLap]

I did the changes and added another test. Thnx for the reviews