Marco.Leise at gmx.de
Wed Oct 12 00:34:28 PDT 2011
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:
>>>> I recommend that everyone take a good look at ActiveRecord in Ruby on
>>> I confess the example you gave looks very foreign to me. From
>>> 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,
>>> 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.
>> 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".
More information about the Digitalmars-d