My initial thought was more around having a new query method (*where.or*)
to solve the specific problem I explained on my first post. However, I've
been thinking about it and I now believe that it's worth trying to tackle
the whole "OR problem".
The problem
Creating where clauses more
> I usually resort to using Arel for more complex queries; not as straight
forward at first, but very powerful I find.
Please note that Arel is a part of Rails' private API, so its direct usage
is not encouraged, since it could change in breaking ways at any time.
(See the Rails docs on what
I usually resort to using Arel for more complex queries; not as straight
forward at first, but very powerful I find.
On Thu, Oct 10, 2019 at 10:15 AM Kevin Deisz wrote:
> For more complex queries, so syntactic sugar can make this a little more
> palatable:
>
> Author.some.complex.scopes.then {
For more complex queries, so syntactic sugar can make this a little more
palatable:
Author.some.complex.scopes.then { |relation| relation.where(first_name:
'John').or(relation.where(last_name: 'Smith')) }.more.complex.scopes
Even better is just extracting that to its own named scope,
scope
I think the idea of making `or` simpler is welcome, but I'm not fond of this
implementation. Passing multiple parameters implies that we're using them
together (like `.not()`), but in this case it implicitly uses parameters
separately (using as an or, that is).
I think something like this
I agree, current approach is not the most convenient one. Have you
considered how would you handle more complex queries, ones where each OR
operand is more than a single equality comparison?
For example:
SELECT * FROM authors WHERE (first_name = 'John' OR last_name = 'Smith') OR
(company LIKE
Consider the following simple query:
SELECT * FROM authors WHERE first_name = 'John' OR last_name = 'Smith'
With ActiveRecord you can write it like this:
Author.where(first_name: 'John').or(Author.where(last_name: 'Smith'))
It’s annoying that you need to pass in a whole relation to the `or`
