[std.database] ORM

simendsjo simendsjo at gmail.com
Thu Oct 13 12:00:51 PDT 2011


On 13.10.2011 20:30, bls wrote:
> Am 13.10.2011 20:16, schrieb simendsjo:
>> On 13.10.2011 19:49, bls wrote:
>>> Am 13.10.2011 18:44, schrieb simendsjo:
>>>> On 13.10.2011 11:53, Steve Teale wrote:
>>>>> On Thu, 13 Oct 2011 11:22:20 +0200, bls wrote:
>>>>>
>>>>>> > Am 12.10.2011 20:13, schrieb Steve Teale:
>>>>>>> >> The way this discussion is going we're going to have four layers,
>>>>>>> with
>>>>>>> >> the top one written by Jacob.
>>>>>> >
>>>>>> > 1 = etc.c.
>>>>>> > 2 = Database classes
>>>>>> > 3 = ??
>>>>>> > 4 = ORM
>>>>>> >
>>>>>> > Please explain ?
>>>>> What I meant was that there might be a layer here that would provide a
>>>>> common interface to the supported databases in terms of literal SQL
>>>>> commands, as embodied in Andrei's example
>>>>>
>>>>
>>>> I was thinking more like
>>>> 1) etc.c.mysql/pg - c interface
>>>> 2) std.sql.mysql/pg - d interface using templates, ranges etc
>>>> 3) Database classes - common interface
>>>> 4) ORM
>>>
>>> Sorry, I don't get it. IMHO 2) and 3) are at the same level.. F.I.
>>> a draft :
>>>
>>> http://pastebin.com/n8H0QF8X
>>>
>>
>> 2) doesn't hide any features of the database. If the database supports a
>> feature, it's here.
>> 3) is a common interface - will hide the specific database, including
>> features unique for this db.
>>
>> At any level, you should be able to drop down to the lower levels if
>> necessary.
>>
>> Of course... 4) could be built directly on 1), 2) or 3). Step 2) isn't
>> really needed as long as you can get internal handles and drop down to
>> 1), but having a clean D interface instead would be nice.
>
> Thanks for the feedback.. I am still not there :)
> from the snippet..
>
> final class MySQL : IDatabase {
> // common _Interface implementation stuff_
> public void open(string host,string db,string user,string pw,
> const string[string] params) {
>
> }
> public void open(string host,string db,string user,string pw) {
> }
> // _MySQL specific_
> public void funkyMySQLstuff() {}
> }
>
> what keeps you away to use .. auto db = new MySQL() ?? the MySQL class
> can be as close to the metal as you want it to be ?
>
> well, guess we have to wait for the first stuff from Steve. It is just
> that I think : design first, implement later.

As long as nothing is missed in the translation, what "layer" exposes 
the db specifics is irrelevant. I'm just afraid that higher levels would 
have stuff like "void funkyMySQLstuff()", while the actual 
implementation would be "ComplexStruct 
funkyMySQLstuff(ParamFromOtherFunkyMethod a, SeveralOtherOptions b)" and 
be missing important options and possible optimizations.


More information about the Digitalmars-d mailing list