On 10/09/11 13:22, Andrei Alexandrescu wrote:
> On 10/9/11 11:40 AM, Steve Teale wrote:
>> Further generic question. (Yes, I am listening to the answers too)
>>
>> If some underlying databases don't support the features that our chosen
>> interface requires, do we attempt to synthesize them - presumably at cost
>> to performance, or do we just throw a compile-time exception that
>> basically tells the user to use a lower interface and code it themself?
>
> No.
>
> Andrei

Sorry, that was awfully unclear. I meant to say the driver shouldn't do little miracles in adapting support from one engine to the next. It's a losing race.

It should be fine if certain queries or API calls fail either statically or dynamically.


Andrei

On 10/9/2011 5:28 AM, Piotr Szturmaj wrote:
> 1. I think that we should not design this API using the least common denominator
> approach. This is to not limit some databases. For example PostgreSQL has many
> great features not available in MySQL. That's why I started with postgres in my
> ddb project. I think DB API should be designed to support the most featureful
> databases and those that have less features may be easily adapted to that API.


Haven't common denominator designs been more or less failures in at least one category - gui libraries?

Some driver models have succeeded only because a powerful entity forced the issue - like for device drivers for an OS.

I suspect that trying to design a common api to popular databases is an expensive and quixotic quest. If it weren't, wouldn't it have happened already?

On 10/7/2011 11:43 PM, Steve Teale wrote:
> I use this title at Andrei's suggestion, and repeat his idea that it be used
> as a prefix for discussions as we navigate toward a design. Unless there is
> resistance to the idea, I will on the job of implementing whatever we decide
> is appropriate. I am retired, and have the time to do it.

Thanks, Steve, for being the champion for this project.

I'd like to suggest that, as a first step, simple translations of the C header files for the various databases be added to etc.c. That'll at least enable people who need to use a database now to get started.

On 10/9/11 5:31 PM, Walter Bright wrote:
> On 10/9/2011 5:28 AM, Piotr Szturmaj wrote:
>> 1. I think that we should not design this API using the least common
>> denominator
>> approach. This is to not limit some databases. For example PostgreSQL
>> has many
>> great features not available in MySQL. That's why I started with
>> postgres in my
>> ddb project. I think DB API should be designed to support the most
>> featureful
>> databases and those that have less features may be easily adapted to
>> that API.
>
>
> Haven't common denominator designs been more or less failures in at
> least one category - gui libraries?

A common database interface is not a common denominator API; more like the opposite. This is not difficult because most differences across database systems lie in their SQL, which is strings from D's perspective.

> Some driver models have succeeded only because a powerful entity forced
> the issue - like for device drivers for an OS.
>
> I suspect that trying to design a common api to popular databases is an
> expensive and quixotic quest. If it weren't, wouldn't it have happened
> already?

It has. All database APIs for programming languages do exactly that.


Andrei

On Oct 9, 2011, at 3:56 PM, Andrei Alexandrescu wrote:

> On 10/9/11 5:31 PM, Walter Bright wrote:
>> On 10/9/2011 5:28 AM, Piotr Szturmaj wrote:
>>> 1. I think that we should not design this API using the least common
>>> denominator
>>> approach. This is to not limit some databases. For example PostgreSQL
>>> has many
>>> great features not available in MySQL. That's why I started with
>>> postgres in my
>>> ddb project. I think DB API should be designed to support the most
>>> featureful
>>> databases and those that have less features may be easily adapted to
>>> that API.
>> 
>> 
>> Haven't common denominator designs been more or less failures in at least one category - gui libraries?
> 
> A common database interface is not a common denominator API; more like the opposite. This is not difficult because most differences across database systems lie in their SQL, which is strings from D's perspective.

Assuming that by "database" you mean SQL.  Pretty fair assumption, though NoSQL databases (which cover a broad range of designs since there's no standard language yet for key-value DBs, etc) are rapidly gaining popularity.  I almost wonder if the base type should be named SqlDatabase instead of Database.

On Sunday, October 09, 2011 16:31:35 Sean Kelly wrote:
> On Oct 9, 2011, at 3:56 PM, Andrei Alexandrescu wrote:
> > On 10/9/11 5:31 PM, Walter Bright wrote:
> >> On 10/9/2011 5:28 AM, Piotr Szturmaj wrote:
> >>> 1. I think that we should not design this API using the least common
> >>> denominator
> >>> approach. This is to not limit some databases. For example
> >>> PostgreSQL
> >>> has many
> >>> great features not available in MySQL. That's why I started with
> >>> postgres in my
> >>> ddb project. I think DB API should be designed to support the most
> >>> featureful
> >>> databases and those that have less features may be easily adapted to
> >>> that API.
> >> 
> >> Haven't common denominator designs been more or less failures in at least one category - gui libraries?
> > 
> > A common database interface is not a common denominator API; more like the opposite. This is not difficult because most differences across database systems lie in their SQL, which is strings from D's perspective.
> Assuming that by "database" you mean SQL.  Pretty fair assumption, though NoSQL databases (which cover a broad range of designs since there's no standard language yet for key-value DBs, etc) are rapidly gaining popularity.  I almost wonder if the base type should be named SqlDatabase instead of Database.

If we were to do that, then maybe it should just be sql, since it's shorter and just as clear: std.sql.*.

- Jonathan M Davis

On 10/9/11 6:31 PM, Sean Kelly wrote:
> On Oct 9, 2011, at 3:56 PM, Andrei Alexandrescu wrote:
>
>> On 10/9/11 5:31 PM, Walter Bright wrote:
>>> On 10/9/2011 5:28 AM, Piotr Szturmaj wrote:
>>>> 1. I think that we should not design this API using the least common
>>>> denominator
>>>> approach. This is to not limit some databases. For example PostgreSQL
>>>> has many
>>>> great features not available in MySQL. That's why I started with
>>>> postgres in my
>>>> ddb project. I think DB API should be designed to support the most
>>>> featureful
>>>> databases and those that have less features may be easily adapted to
>>>> that API.
>>>
>>>
>>> Haven't common denominator designs been more or less failures in at
>>> least one category - gui libraries?
>>
>> A common database interface is not a common denominator API; more like the opposite. This is not difficult because most differences across database systems lie in their SQL, which is strings from D's perspective.
>
> Assuming that by "database" you mean SQL.  Pretty fair assumption, though NoSQL databases (which cover a broad range of designs since there's no standard language yet for key-value DBs, etc) are rapidly gaining popularity.  I almost wonder if the base type should be named SqlDatabase instead of Database.

Good point and good idea.

Andrei

> I'd like to suggest that, as a first step, simple translations of the C header files for the various databases be added to etc.c. That'll at least enable people who need to use a database now to get started.

Walter,

I'm sure they're already out there waiting. I have MySQL. Any offers for Postgres and SQLite?

Does MS-SQL have a C interface these days I wonder?

Steve

On 2011-10-10 00:31, Walter Bright wrote:
> On 10/9/2011 5:28 AM, Piotr Szturmaj wrote:
>> 1. I think that we should not design this API using the least common
>> denominator
>> approach. This is to not limit some databases. For example PostgreSQL
>> has many
>> great features not available in MySQL. That's why I started with
>> postgres in my
>> ddb project. I think DB API should be designed to support the most
>> featureful
>> databases and those that have less features may be easily adapted to
>> that API.
>
>
> Haven't common denominator designs been more or less failures in at
> least one category - gui libraries?
>
> Some driver models have succeeded only because a powerful entity forced
> the issue - like for device drivers for an OS.
>
> I suspect that trying to design a common api to popular databases is an
> expensive and quixotic quest. If it weren't, wouldn't it have happened
> already?

At some level we need a common API for the databases, but still be able to get to database specific API's when there is need for that.

-- 
/Jacob Carlborg

On 2011-10-10 06:54, Steve Teale wrote:
>> I'd like to suggest that, as a first step, simple translations of the C
>> header files for the various databases be added to etc.c. That'll at
>> least enable people who need to use a database now to get started.
>
> Walter,
>
> I'm sure they're already out there waiting. I have MySQL. Any offers for
> Postgres and SQLite?
>
> Does MS-SQL have a C interface these days I wonder?
>
> Steve

I don't know but FreeTDS has implemented the TDS protocol (which SQL server uses). Either we use FreeTDS (LGPL license) or role our own implementation.

-- 
/Jacob Carlborg