[std.database]

[Marco Leise]

Am 12.10.2011, 09:02 Uhr, schrieb Jacob Carlborg <doob at me.com>:

> 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.

It's not like there really is a choice. You just cannot do everything with  
an interface built around objects/structs. But I would use that interface  
most of the time. Ranges for result sets and structs for rows are a very  
natural representation of a SQL query.

Under that aspect, table associations would also be naturally turned into  
pointers. So when a "thread" table refers to the starter through its user  
id, then the thread object would have a pointer to a user object instead  
of just an integer. This makes it easy for example to just fetch a thread  
 from the DB and write "thread.starter.name".
http://docs.jboss.org/hibernate/core/3.3/reference/en/html/performance.html#performance-fetching