[GSOC] Database API draft proposal

[spir]

On 04/03/2011 02:33 PM, 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?

I would go for the second, especially because there is a Python example 
(probably one of the best languages out there for such design questions). Just 
think at usual qualities: clarity / simplicity / consistency (and currently 
discussed Phobos style guidelines).

Also:
* Implementation example(s) is source of feedback for the interface quality.
* Once you've done it, rewriting the exact same feature with a different design 
can be very fast (esp if the change is only about interface), because you 
master the application.

I personly would appreciate an example for a simpler and/or non-relational, 
DBMS (maybe it's only me) (I'm thinking at key:value like Berkeley DB, object 
DBMS, SQLite...).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com