[GSOC] Database API draft proposal

[Fawzi Mohamed]

Well the comments in there are what is important, and will need to be  
specified better IMHO.

The most important part in my opinion is how one chooses to represent  
a record.
A big design choice is if the various fields are defined at compile  
time or at runtime.
Also how does one add special behavior to a record? Do you use a  
subclasses of the generic record type (as ruby does for example)?

D2 adds some more method to allow for generic accessors, so one can  
have a dynamic implementation, while still using static accessors.
Maybe one should allow for both dynamic records and static ones.
The efficient storage of results of a db query is an important point.

Are you aware of http://dsource.org/projects/ddbi for D1?

If one wants to have a nice efficient and well tested interface,  
supporting more than one DB then I think that there is enough work to  
do.

Fawzi
On 3-apr-11, at 14:33, Christian Manning wrote:

> 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