[GSOC] Database API draft proposal

[dsimcha]

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.

According to this page (http://sqlite.org/mostdeployed.html) SQLite is 
probably the most popular database out there and it's definitely the 
most amenable to being fully supported by a standard library (i.e. no 
other dependencies).  I don't know how many times I've wanted to create 
a quick in-memory database and gone with some stupid ad-hoc class with a 
bunch of hashtables and stuff just because I didn't have an SQLite API 
conveniently available.  Yeah, SQLite's not the most scalable thing in 
the world but **you don't always need scalability** and when you do, you 
usually have the resources to deal with a little extra hassle like 
writing some bindings.