On Wednesday, May 25, 2011 4:13:14 PM UTC-6, CarlosCD wrote:
>
> Yes, in my case it was a typo too (a missing s on venues.locality =>
> 'London'). It should be:
>
> Event.find_by_sql("SELECT events.* FROM events INNER JOIN venues ON
> venues.id = events.venue_id WHERE venues.locality = 'London'")
>
> I did test it before posting, but on different models, so my error was when
> changing the entity names to "venues" and "events".
>
> Both sentences (find_by_sql vs. joins.where) generate the same SQL
> statement on the database side, which means that would be equivalent,
> performance-wise. I posted the show the find_by_sql so you can see what it
> does under the hood.
>
Well, yours doesn't _generate_ SQL, it's hard-coded.
>
> I would use one or the other based only on readability of your code. Choose
> the easier to maintain (or add a comment with the SQL statement that
> generates). Being something so simple, ot probably doesn't matter much. I
> like a bit more the "joins.where", more ruby-style than just SQL, but it is
> your choice, they are fully equivalent.
>
>
Yes, as always, choose the best tool for the job at hand. As for readability
and maintainability, I (obviously) like mine better :). It'd take a far more
complex SQL query than this one for me to begin to hard-code SQL fragments.
In fact, with the meta_where (and the rails 3.1 replacement "squeel") gem,
you can pretty much avoid even the smallest SQL fragment, even for
moderately complex queries. it's pretty cool stuff. It's very rails-3-ish to
avoid any SQL (and rely on the relational algebra implemented through arel).
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
