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.

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.

> 
> well, guess we have to wait for the first stuff from Steve. It is just that I think : design first,  implement later.

Steve is working on a level 2 piece for MySQL to get the feel for what can be done and what can't. It is quite close to a viewable state, then I'll be able to hear the groans!

This thread is an information gathering exercise to try to find out what we should do at level 3. It's not going terribly well since everyone has a different point of view. So there is top-down, and bottom-up going on, which I think is perfectly valid.

Steve

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.

Am 13.10.2011, 20:16 Uhr, schrieb simendsjo <simendsjo@gmail.com>:

> On 13.10.2011 19:49, bls wrote:
>> Am 13.10.2011 18:44, schrieb simendsjo:
>>> 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.

2) would be a thin wrapper around the C API. I think that runs against Phobos' philosophy especially with eventually four layers of abstraction. I'm just saying. Wouldn't mind personally.

Jacob Carlborg wrote:

> On 2011-10-12 20:13, Steve Teale wrote:
>> The way this discussion is going we're going to have four layers, with the top one written by Jacob.
> 
> Hehe. As long as there are database connections available in Phobos and a fairly good API with different levels available it should be possible to create an ORM API as a separate project.
> 

That should be the way to go, an ORM is a huge and difficult project.

> 
> 2) would be a thin wrapper around the C API. I think that runs against Phobos' philosophy especially with eventually four layers of abstraction. I'm just saying. Wouldn't mind personally.

Marco,

Not if it's anything like the piece I'm working on, which if I judge by the effort I've put into it, is not thin. Perhaps I'm at the wrong level.

I hope to put an infant version on github before the weekend is out, then you can judge.

Steve

Am 14.10.2011, 09:27 Uhr, schrieb Steve Teale <steve.teale@britseyeview.com>:

>>
>> 2) would be a thin wrapper around the C API. I think that runs against
>> Phobos' philosophy especially with eventually four layers of
>> abstraction. I'm just saying. Wouldn't mind personally.
>
> Marco,
>
> Not if it's anything like the piece I'm working on, which if I judge by
> the effort I've put into it, is not thin. Perhaps I'm at the wrong level.
>
> I hope to put an infant version on github before the weekend is out, then
> you can judge.
>
> Steve

I wanted to say "don't put a lot of work into D wrappers of C APIs unless you know it has a good chance of getting accepted". I didn't realize you already have something more elaborate and I certainly don't want to judge over what piece of good work gets included. There is just probably one layer too much in the mix to make them all obviously distinctive. There seem to be a lot of database bindings from different people and now is the time that they get a chance to become official standard in Phobos. And with so many different approaches and opinions we might need a few votes at some point.
For example I like the layer that hides away the dirty bits (LIMIT vs. TOP, mass INSERTs vs. single row INSERTS, SQL keywords). But since I don't currently use any databases I have no strong opinion.

OK, for what it's worth, the compiler generated documentation (well, more or less) for my mysqlD effort is now on my web site. The same directory also has the source files and a Code::Blocks project for anyone who uses the latter.

I added links to these files at the bottom of the doc.

I'll put the stuff on github as soon as I figure out how. The page for now is:

http://britseyeview.com/software/mysqld/

On 10/14/2011 09:27 AM, Steve Teale wrote:
>>
>> 2) would be a thin wrapper around the C API. I think that runs against
>> Phobos' philosophy especially with eventually four layers of
>> abstraction. I'm just saying. Wouldn't mind personally.
>
> Marco,
>
> Not if it's anything like the piece I'm working on, which if I judge by
> the effort I've put into it, is not thin. Perhaps I'm at the wrong level.
>
> I hope to put an infant version on github before the weekend is out, then
> you can judge.
>
> Steve

nice :-)



---

http://www.mysql.com/about/legal/licensing/foss-exception/

I'm not sure how to interpret this.