d-dbapi ALPHA-2 released

[Kirk McDonald]

Myron Alexander wrote:
> Hello.
> 
> I have released the ALPHA-2 version of D-DBAPI. There is no download 
> package for this release but you can checkout from the Google Code 
> project using tag "alpha-2".
> 
> The D-DBAPI project is a database interface using the PEP239 python 
> specification as a base.
> 
> The project link is : http://code.google.com/p/d-dbapi/
> 
> You can checkout the code using this SVN repository:
> 
> http://d-dbapi.googlecode.com/svn/tags/alpha-2
> 
> My plan is for BETA-1 to be released once the exceptions are designed 
> and implemented. If there are any interface changes, then BETA-2 etc 
> will be released. Once all interface changes and unit tests have been 
> implemented, I will release RC-1 and so forth before releasing V1.
> 
> Regards,
> 
> Myron.
> 
> P.S., any D developers from South Africa?

I always liked Python's DBAPI. One of the benefits of that API is that 
it is, if not always simple, at least reasonably /possible/ to swap out 
one DBMS for another. To that end, you might want the various classes 
involved in your API to all inherit from various interfaces. If you bind 
any DBMSes other than SQLite, they should also inherit from those 
interfaces.

I would also try to find a way to ditch std.boxer. I never liked it. My 
first suggestion, off the top of my head, is something like this:

struct Result(T...) {
     T t;
}

// ... and in e.g. Cursor.fetchall ...
Result!(T)[] fetchall(T ...)() {
     Result!(T)[] r;
     // ... fill r ...
     return r;
}

// And use:
auto values = cu.fetchall!(int, char[] double)();
foreach (row; values) {
     writefln("%d, %s, %#.2f", row.t[0], row.t[1], row.t[2]);
}

The ".t"s are sort of ugly (native tuple return types would sure be 
nice...), but it does get rid of all of those calls to unboxD.

Just some food for thought.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org