[std.database]

[Jacob Carlborg]

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