Hi.

I don't know if this discussion has been brought before. I think it would be good to D programmers to have a standart database API, just like Python has DBAPI 2.0:

http://www.python.org/peps/pep-0249.html

This helps a lot when you're working with diferent DB backends, for example, I'm now in a project were we're migrating a client-server system with a MS SQL server on the server to a linux based server with a Firebird SQL server DB. Since the project is already in production use we're doing it gradually and we've ported the clients first to work under linux against the Windows SQL Server. Once we've completed the server migration the only change we'll have to do is to change our "dbconnect" function and the import to use the Firebird SQL module. Not a single change in the other (client) code will be needed because the connection, cursor and other objects follow exactly the same API.

Also (a little offtopic) the Python "PEP" system would be a good thing to adopt for D (the Phobos/Ares people deciding what "PEP"'s got adopted into the library and Walter which ones into the core language.)

In article <cput07$2cl9$1@digitaldaemon.com>, Juanjo =?iso-8859-1?Q?=C1lvarez?= says...
>
>Hi.
>
>I don't know if this discussion has been brought before. I think it would be good to D programmers to have a standart database API

As most of you know english is not my first language but I figured out what 'standart' means. It might not be totaly correct but means something like "in a distante future".

meanwhile dool defines a database API.
for now I implemented the interface for PostgreSQL and SQLite3.
I'm not sure it's a reasonable API - I didn't even bother to
look at others - but it's familiar to me from other interfaces I used,
and serves the SQL definitions well.

if a standart comes up I would probably change the dool database API.

Ant

PS to have access to the PostgreSQL and SQLite3 you have to
recompile dool with version sqlite3 and/or dpq
(libdp is the PostgreSQL interface).
nothing of this is tested on window and works perfectly on linux.
http://dool.sourceforge.net

In article <cpuv8p$2f04$1@digitaldaemon.com>, Ant says...
>
>
>meanwhile dool defines a database API.

> to have access to the PostgreSQL and SQLite3 you have to
>recompile dool with version sqlite3 and/or dpq
>(libdp is the PostgreSQL interface).
>nothing of this is tested on window and works perfectly on linux.
>http://dool.sourceforge.net
>

here: http://dool.sourceforge.net/dool_sql_Connection_Connection.html http://dool.sourceforge.net/dool_sql_Statement_Statement.html http://dool.sourceforge.net/dool_sql_ResultSet_ResultSet.html http://dool.sourceforge.net/dool_sql_DBMetaTuple_DBMetaTuple.html http://dool.sourceforge.net/dool_sql_DBTuple_DBTuple.html

that's it, as simple as that.

Ant

There is also MySQL.

the MySQL Driver for the programming language D. http://www.steinmole.de/d/

-Hiroshi Sakurai

> I don't know if this discussion has been brought before. I think it would be good to D programmers to have a standart database API, just like Python has DBAPI 2.0:

I agree completely , we defeintly need a uniform interface to all databases .  Hopefully ARES can address this.

Charlie


"Juanjo Álvarez" <juanjo@nospamplease_juanjoalvarez.net> wrote in message news:cput07$2cl9$1@digitaldaemon.com...
> Hi.
>
> I don't know if this discussion has been brought before. I think it would be good to D programmers to have a standart database API, just like Python has DBAPI 2.0:
>
> http://www.python.org/peps/pep-0249.html
>
> This helps a lot when you're working with diferent DB backends, for example, I'm now in a project were we're migrating a client-server system with a MS SQL server on the server to a linux based server with a Firebird SQL server DB. Since the project is already in production use we're doing it gradually and we've ported the clients first to work under linux against the Windows SQL Server. Once we've completed the server migration the only change we'll have to do is to change our "dbconnect" function and the import to use the Firebird SQL module. Not a single change in the other (client) code will be needed because the connection, cursor and other objects follow exactly the same API.
>
> Also (a little offtopic) the Python "PEP" system would be a good thing to adopt for D (the Phobos/Ares people deciding what "PEP"'s got adopted into the library and Walter which ones into the core language.)

I don't think this is quite like what you guys are talking about, but there is some code for ODBC at dsource.

http://www.dsource.org/projects/sdbo/

I looked around a bit, and there's some stuff there.  Maybe someone would want to look deeper.

But again, this isn't like what could be done in Ares - something like JDBC for Java, instead of ODBC.

BA

Charles wrote:
>>I don't know if this discussion has been brought before. I think it
>>would be good to D programmers to have a standart database API, just
>>like Python has DBAPI 2.0:
> 
> 
> I agree completely , we defeintly need a uniform interface to all databases
> .  Hopefully ARES can address this.
> 
> Charlie
> 
> 
> "Juanjo Álvarez" <juanjo@nospamplease_juanjoalvarez.net> wrote in message
> news:cput07$2cl9$1@digitaldaemon.com...
> 
>>Hi.
>>
>>I don't know if this discussion has been brought before. I think it
>>would be good to D programmers to have a standart database API, just
>>like Python has DBAPI 2.0:
>>
>>http://www.python.org/peps/pep-0249.html
>>
>>This helps a lot when you're working with diferent DB backends, for
>>example, I'm now in a project were we're migrating a client-server
>>system with a MS SQL server on the server to a linux based server with a
>>Firebird SQL server DB. Since the project is already in production use
>>we're doing it gradually and we've ported the clients first to work
>>under linux against the Windows SQL Server. Once we've completed the
>>server migration the only change we'll have to do is to change our
>>"dbconnect" function and the import to use the Firebird SQL module. Not
>>a single change in the other (client) code will be needed because the
>>connection, cursor and other objects follow exactly the same API.
>>
>>Also (a little offtopic) the Python "PEP" system would be a good thing
>>to adopt for D (the Phobos/Ares people deciding what "PEP"'s got
>>adopted into the library and Walter which ones into the core language.)
> 
> 
>