On Wed, 12 Oct 2011 09:36:47 +0200, Jacob Carlborg wrote: > On 2011-10-12 09:05, Jonathan M Davis wrote: >> On Wednesday, October 12, 2011 08:57:54 Jacob Carlborg wrote: >>> On 2011-10-11 23:31, Andrei Alexandrescu wrote: >>>> On 10/11/11 3:05 PM, Jacob Carlborg wrote: >>>>> If we're talking use cases and high level interfaces I would go with >>>> >>>>> something like: >>>> [snip] >>>> >>>>> I recommend that everyone take a good look at ActiveRecord in Ruby >>>>> on Rails: >>>>> >>>>> http://guides.rubyonrails.org/active_record_querying.html >>>>> http://guides.rubyonrails.org/association_basics.html >>>>> http://guides.rubyonrails.org/ active_record_validations_callbacks.html >>>> >>>> I confess the example you gave looks very foreign to me. From >>>> consulting http://guides.rubyonrails.org/active_record_querying.html, >>>> I see Ruby's active records esentially recode relational algebra in >>>> Ruby (as for the constructs the equivalent SQL is shown). >>> >>> Yes, exactly. The point is to have as much as possible in functions >>> instead of string literals and have a more Ruby like API than an SQL >>> looking API. >>> >>> connection.select("*").from("users"); >>> >>> instead of >>> >>> connection.execute("select * from users") >> >> I don't know what all of the pros and cons are, since I'm not all that >> experienced with DB stuff, but on the surface at least, from the >> perspective of usability, I don't see anything better about the first >> one than the second one. >> >> - Jonathan M Davis > > I usually prefer calling methods and functions instead of writing > everything in a string literal. > > These forms might not make a big difference but when you use an object > oriented API I think it does. > > Take this Ruby example: > > Post.joins(:comments => :guest) > > Produces the following SQL: > > SELECT posts.* FROM posts > INNER JOIN comments ON comments.post_id = posts.id INNER JOIN guests > ON guests.comment_id = comments.id
But you'd never guess!
