[std.database]

[Jacob Carlborg]

On 2011-10-12 09:34, Marco Leise wrote:
> 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

Yes, this is what ActiveRecord does as well:

http://guides.rubyonrails.org/association_basics.html
http://guides.rubyonrails.org/active_record_querying.html

-- 
/Jacob Carlborg