Can you provide an example of how you would like to see it with merge method?
My real-life case is more like that(we use Paranoia gem, but I show a simplified version): class Article < ApplicationRecord has_many :articles_tags has_many :tags, through: :articles_tags default_scope { where(deleted_at: nil) }end class ArticlesTags < ApplicationRecord belongs_to :article, -> { unscope(where: :deleted_at) } # It intended to affect only articles; I would like to have it like "unscope(where: { articles: :deleted_at })" belongs_to :tag, -> { unscope(where: :deleted_at) } # It intended affect only tags; I would like to have it like "unscope(where: { tags: :deleted_at })"end class Tag < ApplicationRecord has_many :articles_tags has_many :articles, through: :articles_tags default_scope { where(deleted_at: nil) }end When I call Article.joins(:tags) It adds the scope from belongs_to :articles (in this case unscope(where: :deleted_at)) to the where chain and overrides the default scope of tags (where(deleted_at: nil)) even though it was intended to affect different tables On Sunday, March 1, 2020 at 1:27:12 PM UTC+1, Geoff Harcourt wrote: > > Maybe the clearer way to apply it would be to allow unscoping via the > merge method? > > I think the overall idea is worth pursuing in some fashion. We often have > big queries with lots of joins on aggregate dashboards, and ordering on > default scopes for joined models adds wasted expense to queries. The > workarounds are either no default scopes for ordering or joins via SQL > string, which can be inconvenient for a number of reasons. > > On Sat, Feb 29, 2020, 5:07 PM Slava Korolev <kor...@gmail.com > <javascript:>> wrote: > >> Thank you for your feedback! >> >> I think you might misunderstand what I'm proposing, sorry for that. >> You still can unscope as you did before, but if you want to specify table >> you want to affect, you can do it. >> In your example, the current implementation also doesn't work: >> >> Article.where("deleted_at IS NULL").unscope(where: :deleted_at) # == >> SELECT * FROM "articles" WHERE (deleted_at is NULL) >> >> I don't see a way to fix this existing problem. >> But if you don't use custom SQL in your queries you can use both old and >> new approaches: >> >> Article.where(deleted_at: nil).unscope(where: :deleted_at) # == SELECT * >> FROM "articles" >> Article.where(deleted_at: nil).unscope(where: { articles: :deleted_at }) # >> == SELECT * FROM "articles" >> >> >> On Saturday, February 29, 2020 at 4:25:08 PM UTC+1, James Coleman wrote: >>> >>> I think this will likely be confusing in many cases, since it's trivial >>> to come up with example where it won't be able to work as expected. >>> >>> For example, suppose that someone does Article.where("deleted_at IS >>> NULL") in some method (or even harder to find: in a library), then the >>> result of that has unscope(where: {articles: :deleted_at}) called on it. In >>> that case the unscope call will be a no-op, and the result not only >>> surprising, but likely to cause significant application bugs. >>> >>> As such, I'm -1 on this change. >>> >>> On Sat, Feb 29, 2020 at 1:00 AM Slava Korolev <kor...@gmail.com> wrote: >>> >>>> I often see a use case when in a query, there are several relations >>>> with attributes with the same names(for example, in our codebase, there >>>> are >>>> several "soft-deletable" entities, and all of them have deleted_at >>>> attribute). >>>> >>>> Article.where(deleted_at: nil).joins(:comments).where(comments: { >>>> deleted_at: nil }) >>>> >>>> At the moment, it's not possible to unscope deleted_at only for >>>> articles or only for comments. >>>> >>>> I created a PR that adds support for specifying tables in where clauses >>>> in unscope method: >>>> >>>> Article.where(deleted_at: nil).joins(:comments).where(comments: { >>>> deleted_at: nil }).unscope(where: { articles: :deleted_at }) >>>> # == Article.joins(:comments).where(comments: { deleted_at: nil }) >>>> >>>> >>>> PR: https://github.com/rails/rails/pull/38608 >>>> >>>> Happy to get any feedback, 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 rubyonra...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/rubyonrails-core/e5117870-9340-4d86-b81c-0ae75840d486%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/rubyonrails-core/e5117870-9340-4d86-b81c-0ae75840d486%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 rubyonra...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/rubyonrails-core/c044aa68-7fac-4eb6-bb35-93c0cd69e9c6%40googlegroups.com >> >> <https://groups.google.com/d/msgid/rubyonrails-core/c044aa68-7fac-4eb6-bb35-93c0cd69e9c6%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/c311ad8c-9d0a-4b4a-bc6b-03713f7c5b5e%40googlegroups.com.