Fawzi Mohamed wrote:
>
> On 4-apr-11, at 02:01, Piotr Szturmaj wrote:
>
>> Fawzi Mohamed wrote:
>>> [...]
>>> I think that your responses are very relevant, as it seems to me that
>>> your work is nice, and I find that if a GSoC is done in that direction
>>> it should definitely work together with the good work that is already
>>> done, let's don't create multiple competing projects if people are
>>> willing to work together.
>>
>> I'm ready to cooperate :)
>
> great :)
>
>>>>> * support for static and dynamic types.
>>>>> how access of dynamic and static types differs, should be as little as
>>>>> possible, and definitely the access one uses for dynamic types should
>>>>> work without changes on static types
>>>>
>>>> If you mean statically or dynamically typed data row then I can say my
>>>> DBRow support both.
>>>
>>> yes but as I said I find the support for dynamic data rows weak.
>>
>> I've just added row["column"] bracket syntax for dynamic rows.
>
> excellent, ideally that should work also for untyped, because one wants
> to be able to switch to a typed Row without needing to change its code

I used to think the same, but currently this is technically impossible. When I started working on this I wanted one common interface, but tuples use static indexing to their fields. You can't write such code:

Tuple!(int, string) t;

int index = 1;
// try access string field:
t[index] = "abc"; // error

but this works:
t[1] = "abc"; // ok

This problem also applies to structs (FieldTypeTuple). To overcome that we need to split opIndex to compile-time one and run-time one (add static opIndex).

> (and it should work exactly the same, so the typed rows will need to
> wrap things in Variants when using that interface).

Yes, I tried hard to do it. It worked, but it broke Tuple index access - it was hidden by opIndex.

>>>>> * class or struct for row object
>>>>
>>>> I'm using struct, because I think row received from database is a
>>>> value type rather than reference. If one selects rows from one table
>>>> then yes, it is possible to do some referencing based on primary key,
>>>> but anyway I think updates should be done explicitly, because row
>>>> could be deleted in the meantime. In more complex queries, not all of
>>>> selected rows are materialized, i.e. they may be from computed
>>>> columns, view columns, aggregate functions and so on. Allocation
>>>> overhead is also lower for structs.
>>>>
>>>>> * support for table specific classes?
>>>>
>>>> Table specific classes may be written by user and somehow wrap
>>>> underlying row type.
>>>
>>> well with the current approach it is ugly because your calls would be
>>> another type, thus either you remove all typing or you can't have
>>> generic functions, accepting rows, everything has to be a template,
>>> looping on a table or a row you always need a template.
>>>
>>
>> Could you elaborate? I don't know what do you mean.
>
> Well I am not totally sure either, having the row handle better the
> dynamic case i already a nice step forward, I still fear that we will
> have problems with the ORM level, I am not 100% sure, that is the reason
> I would like to try to flesh out the ORM level a bit more.
> I would likethat one can loop on all the tables and for each one get the
> either the generic or the specialized object depending on what is needed.
> If one wants to have business logic in the specialized object it should
> be difficult to bypass them.

Well, it should be possible right now:

struct MyData
{
    int a;
    int b;

    int multiply()
    {
        return a * b;
    }
}

auto cmd = new PGConnection(conn, "SELECT a, b FROM numbers")
auto result = cmd.executeQuery!MyData;

foreach (row; result)
    writeln(row.multiply);

> Maybe I am asking too much and the ORM level should never expose the
> rows directly, because if we use structs we cannot have a common type
> representing a generic row of a DB which might be specialized or not
> (without major hacking).

ORM level may of course expose rows. It should be an additional level of abstraction built on top of SQL api. So one can mix SQL and ORM interfaces.
In regards to common type, it's currently impossible to wrap a Tuple or struct and use [index] access to fields. No matter if we use struct or not.

>>>>> * reference to description of the table (to be able to get also
>>>>> dynamic
>>>>> types by column name, but avoid using too much memory for the
>>>>> structure)
>>>>
>>>> My PostgreSQL client already supports that. Class PGCommand has member
>>>> "fields", which contain information about returned columns. You can
>>>> even check what columns will be returned from a query, before actually
>>>> executing it.
>>>
>>> ok that is nice, and my point is that the type that the user sees by
>>> default should automatically take advantage of that
>>>
>>>>> * Nice to define table structure, and what happens if the db has
>>>>> another
>>>>> structure.
>>>>
>>>> This is a problem for ORM, but at first, we need standard query API.
>>>
>>> I am not so sure about this, yes these (also classes for tables) are
>>> part of the ORM, but the normal users will more often be at the ORM
>>> level I think, and how exactly we want the things look like that the
>>> object level can influence the choice of the best low level interface.
>>
>> A "defined" DBRow or static one, if used on result which has inequal
>> number of columns or their types aren't convertible to row fields then
>> it's an error. But, if someone uses a static fields, he should also
>> take care that the query result is consistent with those fields.
>
> For example doe we want lazy loading of an object from the db? if yes
> how we represent it with current Rows objects?

Could you post an example of lazy loading of an object?

>>>>> * you want to support only access or also db creation and
>>>>> modification?
>>>>
>>>> First, I'm preparing base "traditional" API. Then I want to write
>>>> simple object-relational mapping. I've already written some code that
>>>> generated CREATE TABLE for structs at compile time. Static typing of
>>>> row fields is very helpful here.
>>>
>>> Very good I think that working on getting the API right there and having
>>> it nice to use is important.
>>> Maybe you are right and the current DBRow is indeed the best
>>> abstraction, but I am not yet 100% sure, to me it looks like it isn't
>>> the best end user abstraction (but it might be an excellent low level
>>> object)
>>>
>>
>> I should state here, that end-user usability is very important to me.
>> I should also clarify that my code isn't completely finished and of
>> course it is a subject to change. Any suggestions and critics are
>> welcome :)
>
> very good :)
>

On 03/04/2011 21:53, Andrei Alexandrescu wrote:
> On 4/3/11 3:33 PM, Christian Manning wrote:
>> On 03/04/2011 19:30, Andrei Alexandrescu wrote:
>>> * What coursework did you complete? As a second-year student this makes
>>> it easier for us to assess where you are in terms of expertise. Scores
>>> would help as well.
>>
>> By this do you mean you'd like to see my completed courseworks? Or just
>> descriptions and scores (where available)?
>
> Description and score.
>
> Andrei

Ok, here are the ones I have available.

Internet Software Development:
- XSLT/JSP: 91%
- JSP/MySQL: 70%+ (preliminary grade given in demo)

OO Software Design & Development:
- Data model: 83.33%
- Jetman (create a score + high score system and a configuration panel, MVC style): 80% (preliminary given in demo)

Database Design & Implementation:
- Data Modelling assignment (ERD, normalisation and the like): 69.17%
- Database implementation (of the solution to the previous, in Oracle): not yet marked.

Data Structures & Algorithms:
- Circular doubly linked list with cursor in C: not yet marked.

The only one I can find from last year is a caesar cipher in Haskell: 98%

Sorry about the unmarked ones, these were very recent, but I hope the rest helps.

Chris

On 4/5/11 12:43 PM, Christian Manning wrote:
> On 03/04/2011 21:53, Andrei Alexandrescu wrote:
>> On 4/3/11 3:33 PM, Christian Manning wrote:
>>> On 03/04/2011 19:30, Andrei Alexandrescu wrote:
>>>> * What coursework did you complete? As a second-year student this makes
>>>> it easier for us to assess where you are in terms of expertise. Scores
>>>> would help as well.
>>>
>>> By this do you mean you'd like to see my completed courseworks? Or just
>>> descriptions and scores (where available)?
>>
>> Description and score.
>>
>> Andrei
>
> Ok, here are the ones I have available.
>
> Internet Software Development:
> - XSLT/JSP: 91%
> - JSP/MySQL: 70%+ (preliminary grade given in demo)
>
> OO Software Design & Development:
> - Data model: 83.33%
> - Jetman (create a score + high score system and a configuration panel,
> MVC style): 80% (preliminary given in demo)
>
> Database Design & Implementation:
> - Data Modelling assignment (ERD, normalisation and the like): 69.17%
> - Database implementation (of the solution to the previous, in Oracle):
> not yet marked.
>
> Data Structures & Algorithms:
> - Circular doubly linked list with cursor in C: not yet marked.
>
> The only one I can find from last year is a caesar cipher in Haskell: 98%
>
> Sorry about the unmarked ones, these were very recent, but I hope the
> rest helps.
>
> Chris

Thanks. You may want to paste this in your application.

Andrei

Hello all,

This is the second draft and a lot of changes have been made. Hopefully it's a better overall proposal and I look forward to anybody's feedback :)
---------------------------------

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
-------
Piotr Szturmaj has began working on DDB [1] which has a PostgreSQL clietn written in D as well as some database neutral features such as the DBRow type for storing rows from a database. Piotr and I have agreed to collaborate such that DDB will continue with Piotr at the helm, and I will begin implementing other DBMS clients based around his work. Once there is another implementation, work will then begin on extracting a common interface which will form the API.
For example:

module database;

interface DBConnection {
    //method definitions for connecting to databases go here.
}

Then in an implementation of MySQL:

module mysql;

import database;

class Connection : DBConnection {
    //implement defined methods tailoring to MySQL.
}

Exactly what will go in to these interfaces will depend on the differences between the DBMSs, but they all share many things. The API should also be developed in conjunction with the D community to minimise any fallout of decisions made.

The DBMSs I plan to implement are MySQL and SQLite. Unlike PostgreSQL, MySQL doesn't seem to have a long-term and stable client-server protocol. As a result of this I will be wrapping around the MySQL C API (v5.1) to bring it to D. SQLite will also undergo the same process. Because of this, these clients are not likely to get into Phobos and so, if the API does then these will be an external package.

If this project is completely successful, there will be a database API and at least three DBMS clients ready for use in D applications. The minimum amount of functionality for this to be considered successful would be an API that is mostly utilised by the PostgreSql and MySQL clients. In this scenario there will still be two usable clients, however, perhaps the API is not totally complete and neither is the SQLite client.

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.

Grades From The Past Year
-------------------------
Internet Software Development:
- XSLT/JSP: 91%
- JSP/MySQL: 70%+ (preliminary grade given in demo)

OO Software Design & Development:
- Data model: 83.33%
- Jetman (create a score + high score system and a configuration panel,
MVC style): 80% (preliminary given in demo)

Database Design & Implementation:
- Data Modelling assignment (ERD, normalisation and the like): 69.17%
- Database implementation (of the solution to the previous, in Oracle):
not yet marked.

Data Structures & Algorithms:
- Circular doubly linked list with cursor in C: not yet marked.

Computational Modelling (1st year):
- Caesar cipher in Haskell: 98%

References
----------
[1] https://github.com/pszturmaj/ddb http://pszturmaj.github.com/ddb/db.html

On Wed, 06 Apr 2011 05:38:02 +0900, Christian Manning <cmanning999@gmail.com> wrote:

> Hello all,
>
> This is the second draft and a lot of changes have been made. Hopefully it's a better overall proposal and I look forward to anybody's feedback :)
> ---------------------------------
>
> 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
> -------
> Piotr Szturmaj has began working on DDB [1] which has a PostgreSQL clietn written in D as well as some database neutral features such as the DBRow type for storing rows from a database. Piotr and I have agreed to collaborate such that DDB will continue with Piotr at the helm, and I will begin implementing other DBMS clients based around his work. Once there is another implementation, work will then begin on extracting a common interface which will form the API.
> For example:
>
> module database;
>
> interface DBConnection {
>      //method definitions for connecting to databases go here.
> }
>
> Then in an implementation of MySQL:
>
> module mysql;
>
> import database;
>
> class Connection : DBConnection {
>      //implement defined methods tailoring to MySQL.
> }
>
> Exactly what will go in to these interfaces will depend on the differences between the DBMSs, but they all share many things. The API should also be developed in conjunction with the D community to minimise any fallout of decisions made.
>
> The DBMSs I plan to implement are MySQL and SQLite. Unlike PostgreSQL, MySQL doesn't seem to have a long-term and stable client-server protocol. As a result of this I will be wrapping around the MySQL C API (v5.1) to bring it to D. SQLite will also undergo the same process. Because of this, these clients are not likely to get into Phobos and so, if the API does then these will be an external package.
>
> If this project is completely successful, there will be a database API and at least three DBMS clients ready for use in D applications. The minimum amount of functionality for this to be considered successful would be an API that is mostly utilised by the PostgreSql and MySQL clients. In this scenario there will still be two usable clients, however, perhaps the API is not totally complete and neither is the SQLite client.
[snip]
> References
> ----------
> [1] https://github.com/pszturmaj/ddb http://pszturmaj.github.com/ddb/db.html
>

Hmm.. In what way is your new module different from DDBI?
What's the new features?


Masahiro

Masahiro Nakagawa wrote:
>> [1] https://github.com/pszturmaj/ddb http://pszturmaj.github.com/ddb/db.html
>>
> 
> Hmm.. In what way is your new module different from DDBI? What's the new features?

I should state here that work on DDB is in progress, so it's subject to change. However, notable differences from DDBI are typed rows, where one can map structs/tuples/arrays or base types directly to the result. For example:

enum Axis { x, y, z }
struct SubRow1 { string s; int[] nums; int num; }
alias Tuple!(int, "num", string, "s") SubRow2;
struct Row { SubRow1 left; SubRow2[] right; Axis axis; string text; }

auto cmd = new PGCommand(conn, "SELECT ROW('text', ARRAY[1, 2, 3], 100),
                                ARRAY[ROW(1, 'str'), ROW(2, 'aab')],
'x', 'anotherText'");

auto row = cmd.executeRow!Row; // map result to Row struct

assert(row.left.s == "text");
assert(row.left.nums == [1, 2, 3]);
assert(row.left.num == 100);
assert(row.right[0].num == 1 && row.right[0].s == "str");
assert(row.right[1].num == 2 && row.right[1].s == "aab");
assert(row.axis == Axis.x);
assert(row.s == "anotherText");

This is done without intermediate state, such as Variant. In case of PostgreSQL binary encoding, values are directly read into struct fields. Also, typed rows form the basis of the ORM.

Dynamic rows are also first class citizens:

cmd = new PGCommand(conn, "SELECT * FROM table");
auto result = cmd.executeQuery; // range of DBRow!(Variant[])

foreach (row; result)
{
    writeln(row["column"]);
}

result.close;

Some parts of the Connection/Command classes are currently modeled after ADO.NET.

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

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.

On 04/12/2011 04:15 AM, dsimcha wrote:
> 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.

Agreed...

> 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.

...as well.

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

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.