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 :named, ->(first_name, last_name) { where(first_name:
first_name).or(where(last_name: 'Smith')) }
Author.some.complex.scopes.named(first_name, last_name).more.complex.scopes
I get that that doesn't solve your concern with the API, but it makes it
more readable for sure.
On Thu, Oct 10, 2019 at 9:03 AM Rolandas Barysas <r...@atomicflow.org> wrote:
> 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 would be more readable:
>
> Author.where(first_name: 'John').or(last_name: 'Smith')
>
> Right now in your particular case you can write like this, though I assume
> you're trying to avoid using SQL at all:
>
> Author.where('first_name = ? OR last_name = ?', 'John', 'Smith')
>
> On Thu, Oct 10, 2019, at 11:52, Vicente Romero Calero wrote:
>
> 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`
> function. It would be nicer to have something shorter and cleaner. So, I
> propose to add a `where.or` query method, similar to the existing
> `where.not`. This new method would take params in the same way `where`
> does, but instead of using AND as a keyword to join the predicates, it
> would use OR. The query above would be built as follows:
>
> Author.where.or(first_name: 'John', last_name: 'Smith')
>
> I’m not sure if I’m missing something fundamental that makes this feature
> difficult to implement. I’ve actually implemented a working version and I’d
> be happy to push a PR if the feedback is positive.
>
> Besides the technical challenges that may arise, do you think it’s a
> useful feature?
>
> Thanks!
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rubyonrails-core/125f930d-73ef-4dab-b353-77a8f2e4280a%40googlegroups.com
> <https://groups.google.com/d/msgid/rubyonrails-core/125f930d-73ef-4dab-b353-77a8f2e4280a%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rubyonrails-core/3cb23264-3d5a-4b27-b6b4-b541a08e8b99%40www.fastmail.com
> <https://groups.google.com/d/msgid/rubyonrails-core/3cb23264-3d5a-4b27-b6b4-b541a08e8b99%40www.fastmail.com?utm_medium=email&utm_source=footer>
> .
>
--
*Kevin D. Deisz*
CTO, CultureHQ <https://www.culturehq.com>
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/rubyonrails-core/CALzDYJ0hufhkNgEQvwDYd1nA9LBzrnU_4tWK%2B2KPpd80xi_b9A%40mail.gmail.com.
