Hi, i saw all discuss here, but i consider not a really useful use case
for describe the usage for AR's merge, here is make up example.
```rb
class Book < ActiveRecord::Base
belongs_to :category
# here we define a AR scope.
# we can use it easily like this:
# Book.borrowed => return all borrowed books
scope :borrowed -> do
where(was_borrowed: true)
end
end
class Category < ActiveRecord::Base
has_many :books
end
# we can reuse scoped logic defined on Book (Book.brrowed)
# here, to avoid duplicate code, what i mean is, we don't need write it like
this.
# Category.joins(:books).merge(books: {was_borrowed: true})
# the advantage is: if query for Book.brrowed was changed in Book model,
# all merge place take effect immediately.
Category.joins(:books).merge(Book.brrowed)
So, I just curious, @Jeremy, is there exists a similar usage like `merge` here?
(with scope like equivalent)
Jeremy Evans <jeremyeva...@gmail.com> writes:
> On Mon, Dec 13, 2021 at 10:29 AM Tiago Cardoso <honeyryderch...@gmail.com>
> wrote:
>
> A segunda-feira, 13 de dezembro de 2021 à(s) 18:12:19 UTC, Jeremy Evans
> escreveu:
>
> On Mon, Dec 13, 2021 at 9:03 AM Tiago Cardoso <honeyry...@gmail.com> wrote:
>
> .intersect is definitely not covering my use-case.
>
> Could you explain why? For the example you gave, results should be
> identical.
>
> The example above is probably not matching the real use-case I'd like to
> cover, which is found here:
>
> https://gitlab.com/honeyryderchuck/rodauth-oauth/-/merge_requests/69/diffs#eba3d8d3b7f624088a30cbc09948382d6dd2354e_687_702,
> which blows with "Sequel::DatabaseError: SQLite3::SQLException: SELECTs to
> the left and right of INTERSECT do not
> have the same number of result columns" in the test suite if I use
> ".intersect", which I assume isn't to be used with
> joined tables.
>
> You can use #intersect, you just need to make sure the same columns are
> selected in both datasets (or at least, the same
> number). This is definitely a case where even if Dataset#merge was
> supported, I would have it raise an error.
>
> If you ever change your mind about Dataset#merge, I guess that it'd be
> possible to constrain it to handle only
> "simple" cases (i.e. no different tables, but potentially handling merging
> joins, conditions, ...). I know that AR
> supports something of the kind, which has worked in the past for me for the
> simple cases, but you might know quite a
> bit more about the implementation overhead than me.
>
> I 100% want to avoid AR's issues with #merge. Look Rails 7.0 CHANGELOG for
> AR
> (https://github.com/rails/rails/blob/7-0-stable/activerecord/CHANGELOG.md)
> and search for "merge". Please let me
> know what you think about the behavior.
>
>
> If you look at the reasoning behind merge given in the AR documentation:
> "This is mainly intended for sharing
> common conditions between multiple associations.". Due to Sequel's
> extensive support for SQL expression objects
> as part of it's API (instead of SQL string fragments with placeholders), you
> can almost always share common
> conditions in a Sequel object, and use the shared conditions in multiple
> datasets.
>
> I'm definitely in favour of not importing AR's maintenance burden to sequel.
> I guess I was looking for a "terser" way
> for doing what I am in the linked example above, but perhaps it's not AR's
> merge feature, and I'm best served with
> Dataset#opts already.
>
> Agreed.
>
> Thanks,
> Jeremy
--
Thanks,
Billy
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sequel-talk+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sequel-talk/87y24pis7l.fsf%40gmail.com.
