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.
