[GSOC] Database API draft proposal

[Christian Manning]

On 03/04/2011 13:10, spir wrote:
> On 04/02/2011 10:03 PM, Christian Manning wrote:
>
>> I plan to have several interfaces in a database module which are then
>> implemented for specific DBMSs.
>> For example:
>>
>> module database;
>>
>> interface Connection {
>> //method definitions for connecting to databases go here.
>> }
>>
>> Then in an implementation of MySQL for example:
>>
>> module mysql;
>>
>> import database;
>>
>> class Connect : Connection {
>> //implement defined methods tailoring to MySQL.
>> }
>
> I would recommend to use slightly longer names for generic interfaces,
> eg "IConnection" or "DBConnection". Then, authors of libraries /
> implementations for specific DBMS like MySQL can use the shorter ones,
> eg "Connection", which will be all what library clients will see and
> use. This also avoids the need for "lexical hacks" like "Connection"
> versus "Connect".
> What do you think?

When I was writing that it really didn't sit well and "DBConnection" in 
particular is a much better way of doing it to reduce some confusion there.

>> What goes in to these interfaces will be decided in conjunction with
>> the D
>> community so that there is minimal conflict and it will benefit as many
>> circumstances as possible. I believe this to be the best route to take
>> as I
>> cannot speak for everyone who will be using this.
>>
>> Using the API created I plan to create an example implementation,
>> initially
>> wrapping around the MySQL C API. This will be a good starting point
>> for this
>> project and more can be created, time permitting.
>
> I have no idea of the actual size of such an interface design, but I
> doubt it can make you busy for 3 months full time, especially since
> there are (probably good) precedents for other languages. Maybe the
> example implementation should be specified as part of the project?

I'm aware that it wouldn't take 3 months, but I don't know how long it 
will take to have the API agreed upon so that there's a general 
consensus. Another way I could do it is to decide on the API myself and 
begin implementing DBMSs with it and then adapt to the ideas brought 
forth by the community. Then, everyone's happy, just in a different time 
frame. Though, if there are a lot of changes wanted I'd have to change 
all of my implementations depending on how far I am at the time. What do 
you think about that path?

Thanks for the feedback, it's much appreciated :)

Chris