On 2011-10-12 02:43, Johann MacDonagh wrote:
On 10/11/2011 5:31 PM, 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).
For a variety of reasons, this would be tenuous in D. One simple reason
is that e.g. lambdas don't offer access to textual representation, which
would be necessary to translate lambda-based conditions into SQL text.
I might be narrow-minded, but I thought we're still looking at writing
and executing good old SQL code.
Andrei
We should always allow the user to get down to the nitty-gritty and
write good ol' SQL statements and execute them. However, writing all
that plumbing code gets old very quickly, so if we can provide some
clean and simple frameworks on top of that, users would appreciate it.
Yes, exactly. The point of having several layers built on top of each
other is that everyone is free to choose on which layer they want to
interact with the database.
If someone is comfortable with interacting with the database in an
object oriented API they're free to do that. If they're instead more
comfortable in executing raw SQL, then that's possible as well.
--
/Jacob Carlborg
