[GSOC] Database API draft proposal

Christian Manning cmanning999 at gmail.com
Sun Apr 3 07:07:18 PDT 2011


On 03/04/2011 14:16, spir wrote:
> 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

SQLite could definitely be on the table. However, I don't want to be 
over-ambitious at this stage and then not complete the project, and all 
advice I've read on applying for GSOC suggests this too. If I could be 
more certain on the time it would take for the API alone, then I would 
propose more.
Would it be suitable to have something like: "If the API is not in a 
good state by xx/xx/2011 then y implementation will not be undertaken" ?


More information about the Digitalmars-d mailing list