Didn't realize you were the one who was the OP. Regardless, your
comment is confusing. You mention you have it working with scoping in
your first message and then you ask if it should work with scoping???
Ignore my message then. As you were. :)
On 8/5/06, Blake Watters <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Right, because I've hacked the support in there for my app. The whole
question is whether I should leave this mess in my lib, make it a
plugin or patch it against core. John Susser pointed out that you can
do it by gluing onto the :group key and my counterpoint is that
scopings make the case for :having over :group => 'foo having count
(id)'. I was just trying to illustrate why :having is a win over
group by piggybacking.
I don't really see the point of sending my own sentences back to me
when you aren't illustrating a viable point or contributing to the
discussion.
On Aug 5, 2006, at 1:54 PM, Andrew Kaspick wrote:
>> From the OP's message....
>
> "This has reached stability and now works with eager loading and
> scopings,"
>
> On 8/5/06, Blake Watters <[EMAIL PROTECTED]> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> The other thing that occurs to me is that I can imagine
>> wanting :having to be subject to scoping. Most of my most interesting
>> queries these days are coming from nested scopes. Backpacking
>> onto :group may make this non-trivial, where adding a :having option
>> and threading it through the Active Record plumbing would let you
>> work more naturally:
>>
>> Article.with_scope(:find => { :conditions => "blog_id = 1", :having
>> => 'count(tags.id) > 0', :include => 'tags'}) do
>> Article.with_scope(:find => { :having => 'count(categories.id) =
>> #{category_list.size}', :conditions => ['categories.id IN (?)',
>> category_list], :include => :categories }
>> Article.find(:all, :group => 'articles.id)) # => SELECT * from
>> articles AND categories.id IN (1, 2, 3, 4, 5) LEFT JOIN categories on
>> categories.id WHERE blog_id = 1 GROUP BY articles.id HAVING count
>> (categories.id) = 5
>> end
>> end
>>
>> On Aug 5, 2006, at 1:28 PM, Blake Watters wrote:
>>
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> >
>> > Interesting. The queries I'm generating get pretty nasty and
>> > there's something to be said for the symmetry offered by a key in
>> > the options and documentation, etc. I can probably unwind
>> > the :having stuff I've done and glue it all onto the :group clause
>> > if I'm one of the few people who care about it and use it, but it
>> > makes my OCD twitch a little. But I can always leave the :having
>> > hackery I've added to my query generation stuff tucked away in my
>> > lib/ to allay my cleanliness obsession.
>> >
>> > I think this is a relatively low hanging add, but its pointless for
>> > me to toil away extracting in into a patch if nobody cares or wants
>> > the extra key.
>> >
>> > On Aug 5, 2006, at 12:08 PM, Josh Susser wrote:
>> >
>> >>
>> >> On Aug 4, 2006, at 11:19 PM, Blake Watters wrote:
>> >>> I have recently needed support for having clauses for some
>> >>> advanced find queries in my application. I've implemented this in
>> >>> a mixin that implements a new set of finders and query
>> >>> constructors that mirror the core Active Record, except for the
>> >>> additional support for :having as an argument. This has reached
>> >>> stability and now works with eager loading and scopings, so I'd
>> >>> like to extract it from my application as a patch against Active
>> >>> Record core.
>> >>
>> >> I'm using HAVING just fine already. Just append the HAVING clause
>> >> to the end of the :group option.
>> >>
>> >> find(:all, :readonly => false,
>> >> :select => "articles.*",
>> >> :joins => "INNER JOIN taggings t ON articles.id =
>> t.article_id",
>> >> :conditions => ["t.tag_id IN (?)", tag_list], :order => order,
>> >> :group => "articles.id HAVING COUNT(articles.id) = #
>> >> {tag_list.size}")
>> >>
>> >> Is there something you're using HAVING for that needs more
>> >> flexibility than that?
>> >>
>> >> --
>> >> Josh Susser
>> >> http://blog.hasmanythrough.com
>> >>
>> >>
>> >> _______________________________________________
>> >> Rails-core mailing list
>> >> Rails-core@lists.rubyonrails.org
>> >> http://lists.rubyonrails.org/mailman/listinfo/rails-core
>> >
>> > -----BEGIN PGP SIGNATURE-----
>> > Version: GnuPG v1.4.3 (Darwin)
>> >
>> > iD8DBQFE1NU8qvuZB2zXNU0RAqJNAJwOdTBIeiwoTY3ENT27a8wkz/BJzwCg0D+n
>> > OMV6NuOoxgjEB6yGwJUyuY4=
>> > =ihXG
>> > -----END PGP SIGNATURE-----
>> > _______________________________________________
>> > Rails-core mailing list
>> > Rails-core@lists.rubyonrails.org
>> > http://lists.rubyonrails.org/mailman/listinfo/rails-core
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.3 (Darwin)
>>
>> iD8DBQFE1NnbqvuZB2zXNU0RAgGgAJoDfjC+KOMp18OTdvQP9BsCBcIkBACgz2Tc
>> +FWx02MUovgenC12/ZO6QHo=
>> =dfcH
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> Rails-core mailing list
>> Rails-core@lists.rubyonrails.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails-core
>>
> _______________________________________________
> Rails-core mailing list
> Rails-core@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-core
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
iD8DBQFE1N3KqvuZB2zXNU0RAklVAJ901QV+bNBPBnq2GrlXdTfDjBA2bACfS4Nx
p8Mz6OagBAUeRKrPZyysDbk=
=wpsa
-----END PGP SIGNATURE-----
_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
