[GSOC] Database API draft proposal

[Piotr Szturmaj]

dsimcha wrote:
> On 4/11/2011 10:01 PM, Daniel Gibson wrote:
>> Am 02.04.2011 22:03, schrieb Christian Manning:
>>> Hello all,
>>>
>>> This is my first draft proposal for a Database API for Google Summer Of
>>> Code. I have never written a document such as this so any and all
>>> feedback is welcome.
>>>
>>> Thanks
>>> ---------------------------------
>>>
>>> Synopsis
>>> --------
>>> An API for databases is a common component of many languages' standard
>>> library, though Phobos currently lacks this. This project will remedy
>>> this by providing such an API and also begin to utilise it with
>>> interfaces for some Database Management Systems (DBMS). I believe this
>>> will benefit the D community greatly and will help bring attention and
>>> developers to the language.
>>>
>>> Details
>>> -------
>>> This project takes influence from the Java Database Connectivity API
>>> (JDBC), the Python Database API v2 and other similar interfaces. The
>>> idea is that any database interface created for use with D will follow
>>> the API so that the only thing to change is the database back-end being
>>> used. This will make working with databases in D a much easier
>>> experience.
>>>
>>> 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.
>>> }
>>>
>>> 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.
>>>
>>> About Me
>>> --------
>>> My name is Christian Manning and I am a second year undergraduate
>>> studying Computer Science at De Montfort University.
>>> I've become interested in D over time after reading about it several
>>> years ago. I got myself "The D Programming Language" and went from
>>> there. Although I've not done anything useful in D as I've learnt mainly
>>> C and Java and am unable to use D for my university projects, I think
>>> I'm capable of achieving the goals of this project.
>>
>> Something I just posted in another thread and I think is quite important
>> for D's Database support:
>>
>> I think most databases (and their libs) are under a license that
>> is not free enough for Phobos (SQLite is an exception - it's Public
>> domain - and thus can and should be shipped with Phobos).
>> So I guess Phobos' DB support should be written in a way that allows
>> plugging in a DB driver that is distributed independently and under a
>> different license (this makes sense anyway, because maintaining drivers
>> for dozens of databases in Phobos is too much work). Maybe we'd need
>> proper DLL support for that?
>> This model is used by ODBC and JDBC as well.
>>
>> So you should probably think about how external drivers (not shipped
>> with Phobos and not known when Phobos is compiled) can be implemented
>> and loaded - but maybe this needs proper DLL/shared library support that
>> is not yet available afaik.
>>
>> Cheers,
>> - Daniel
>
> Makes sense. I think 110% that SQLite should be the top priority w.r.t.
> database stuff. SQLite bindings and a good D API with some dependency
> inversion so the high-level API can be reused with other database
> backends would be a great GSoC project, even if nothing involving other
> backends is actually implemented.

I agree that SQLite should be here but I think DB API should be 
prototyped using the most featureful/advanced database system, i.e. 
Oracle / PostgreSQL. An API covering those databases would certainly 
support less advanced ones, such as SQLite.