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.