Greetings,

After some feedback and much work, 0.1.5 of ddbi is available:

http://jeremy.cowgar.com/ddbi/

This new release includes support for:

  * SQLite v3
  * MySQL
  * PostgreSQL

A simple example on it's usage:

import dbi.sqlite.SqliteDatabase;
//import dbi.pg.PgDatabase;
//import dbi.mysql.MysqlDatabase;

void main() {
  // PgDatabase db = new PgDatabase();
  // MysqlDatabase db = new MysqlDatabase();
  // db.connect("dbname=test");

  SqliteDatabase db = new SqliteDatabase();
  db.connect("_test.db");

  Row[] rows = db.queryFetchAll("SELECT * FROM names");
  for (Row row; rows) {
    printf("name: %.*s zip: %.*s\n", row["name"], row["zip"]);
  }

  db.close();
}

----
Jeremy Cowgar
http://jeremy.cowgar.com/

In article <d467mn$134g$1@digitaldaemon.com>, Jeremy Cowgar says...
>
>Greetings,
>
>After some feedback and much work, 0.1.5 of ddbi is available:
>
>http://jeremy.cowgar.com/ddbi/
>
>This new release includes support for:
>
>   * SQLite v3
>   * MySQL
>   * PostgreSQL
>
>A simple example on it's usage:
>
>import dbi.sqlite.SqliteDatabase;
>//import dbi.pg.PgDatabase;
>//import dbi.mysql.MysqlDatabase;
>
>void main() {
>   // PgDatabase db = new PgDatabase();
>   // MysqlDatabase db = new MysqlDatabase();
>   // db.connect("dbname=test");
>
>   SqliteDatabase db = new SqliteDatabase();
>   db.connect("_test.db");
>
>   Row[] rows = db.queryFetchAll("SELECT * FROM names");
>   for (Row row; rows) {
>     printf("name: %.*s zip: %.*s\n", row["name"], row["zip"]);
>   }
>
>   db.close();
>}

I'm exicted about this project: I'm working on something myself that could really use a good database lib.  Could you share with us what the future might bring for this project?

- EricAnderton at yahoo

> I'm exicted about this project: I'm working on something myself that could
> really use a good database lib.  Could you share with us what the future might
> bring for this project?

It's current state is a tracer bullet. With the addition of PostgreSQL and MySQL I am now going to (hopefully with the help of the D community) work on making a solid API. Numerous suggestions for number of rows in a result set, etc...

Once the API is solid, I would then begin to request others to create and contribute more database drivers. In the end, it is the hope that this project will provide a robust, feature rich, totally consistent interface to multiple database systems.

It is also the hopes that many classes will be added to ease in SQL database development, such as making complex where clauses, select statements, etc... This would be in addition to the dbi interface.

Yet one more avenue to help SQL programmers would be some type of DAO classes to provide something like:

class Person : DAO {
  private {
    char[] m_name;
    char[] m_zip;
  }
}

Person p = new Person();
p.m_name = "John Doe";
p.m_zip = "11223";

db.save(p);

... who knows about that interface, I have not thought that far ahead. Currently it's goal is to provide cross-database access in a common interface.

----
Jeremy Cowgar
http://jeremy.cowgar.com/ddbi/

I just have to say this is cool!

Jeremy Cowgar wrote:
>> I'm exicted about this project: I'm working on something myself that could
>> really use a good database lib.  Could you share with us what the future might
>> bring for this project?
> 
> 
> It's current state is a tracer bullet. With the addition of PostgreSQL and MySQL I am now going to (hopefully with the help of the D community) work on making a solid API. Numerous suggestions for number of rows in a result set, etc...
> 
> Once the API is solid, I would then begin to request others to create and contribute more database drivers. In the end, it is the hope that this project will provide a robust, feature rich, totally consistent interface to multiple database systems.
> 
> It is also the hopes that many classes will be added to ease in SQL database development, such as making complex where clauses, select statements, etc... This would be in addition to the dbi interface.
> 
> Yet one more avenue to help SQL programmers would be some type of DAO classes to provide something like:
> 
> class Person : DAO {
>   private {
>     char[] m_name;
>     char[] m_zip;
>   }
> }
> 
> Person p = new Person();
> p.m_name = "John Doe";
> p.m_zip = "11223";
> 
> db.save(p);
> 
> ... who knows about that interface, I have not thought that far ahead. Currently it's goal is to provide cross-database access in a common interface.
> 
> ----
> Jeremy Cowgar
> http://jeremy.cowgar.com/ddbi/

Are all fileds in selected rows have string type?
What about numbers, date etc?

>   Row[] rows = db.queryFetchAll("SELECT * FROM names");
>   for (Row row; rows) {
>     printf("name: %.*s zip: %.*s\n", row["name"], row["zip"]);
>----
>Jeremy Cowgar
>http://jeremy.cowgar.com/

novice2 wrote:
> Are all fileds in selected rows have string type?
> What about numbers, date etc?

At this point, yes. This will change however. If you take a peek at MysqlDatabase and PgDatabase you will see that they are not yet retrieving column type. Once this portion is complete, you will then be able to retrieve different types.

I am open as to what everyone thinks I should do with date's and times. D has support for d_time, but it doesn't seem very friendly to convert a d_time into a string format for use by a human.

Also, the type retrieval. D will not support overloading functions based on return type, so it seems I would have to do something like:

row.getInt("age");
row.getDate("dob");
row.getLong("id");

Any thoughts? Thinking about this, if this is the case, I don't have to wait for the underlying dbi drivers to support retrieving types.

Jeremy

>D will not support overloading functions based on return type

yes. it is a pity :(

>Any thoughts? Thinking about this, if this is the case, I don't have to wait for the underlying dbi drivers to support retrieving types.

i need, and, may be, will implement basic functionality of oracle driver.
and i need db interface spec.
i have not thoughts about, sorry.

In article <d48c6j$3s2$1@digitaldaemon.com>, Jeremy Cowgar says...
>
>I am open as to what everyone thinks I should do with date's and times. D has support for d_time, but it doesn't seem very friendly to convert a d_time into a string format for use by a human.

I'd reccomend something along the lines of the SQL style date/time conversion routines.  That way, you'd have symmetry between D and SQL when manipulating database data.  It wouldn't have to be an exact match, but at least using the same convetions for datePart and friends would help.

Another option would be to use something like what PHP date() has: http://www.php.net/manual/en/function.date.php

.. could be useful as it's own module, or even in Ares.

If you surf the main DNG (read: google the heck out of the site), I think you'll find some discussion to this effect a few months back.

>
>Also, the type retrieval. D will not support overloading functions based on return type, so it seems I would have to do something like:
>
>row.getInt("age");
>row.getDate("dob");
>row.getLong("id");
>
>Any thoughts? Thinking about this, if this is the case, I don't have to wait for the underlying dbi drivers to support retrieving types.

It makes for more readable code IMO, to go with this technique.  At a glance, I can see what conversions are being used.   Also, you'll probably find that the DBI drivers that support type information, can be used to accelerate otherwise costly conversion operations (Eg. if a value is already int, than getInt() will just return directly)

Aside: It's actually a small blessing that D doesn't overload based on return type. Otherwise, we get this:

void foo(int a);
void foo(double a);

int bar();
double bar();

foo(bar());  //which combination gets called?

- EricAnderton at yahoo

On Thu, 21 Apr 2005 14:27:43 +0000, novice2 wrote:

>>D will not support overloading functions based on return type
> 
> yes. it is a pity :(
> 
>>Any thoughts? Thinking about this, if this is the case, I don't have to wait for the underlying dbi drivers to support retrieving types.
> 
> i need, and, may be, will implement basic functionality of oracle driver.
> and i need db interface spec.
> i have not thoughts about, sorry.


I don't currently have a spec created, however it is very easy to look at the two Interfaces that you must implement, Database and Result. Both of these have a class that implements some basic functionality, BaseDatabase and BaseResult. You can look at SqliteDatabase.d and SqliteResult for a good example on how to use these.

Jeremy

Jeremy Cowgar wrote:
> novice2 wrote:
> 
>> Are all fileds in selected rows have string type?
>> What about numbers, date etc?
> 
> 
> At this point, yes. This will change however. If you take a peek at MysqlDatabase and PgDatabase you will see that they are not yet retrieving column type. Once this portion is complete, you will then be able to retrieve different types.
> 
> I am open as to what everyone thinks I should do with date's and times. D has support for d_time, but it doesn't seem very friendly to convert a d_time into a string format for use by a human.
> 
> Also, the type retrieval. D will not support overloading functions based on return type, so it seems I would have to do something like:
> 
> row.getInt("age");
> row.getDate("dob");
> row.getLong("id");
> 
> Any thoughts? Thinking about this, if this is the case, I don't have to wait for the underlying dbi drivers to support retrieving types.
> 
> Jeremy
How about representing time as the number of seconds (0.1 seconds?  0.01 seconds?) since midnite 12/31/1999?  Use a signed 64 bit int, and depend on a time library to convert it into the desired format?  This allows times to be stored in a compact form, and YOU don't need to worry about leap seconds, etc. You're just dealing with int's.)  Also figure out the desired time range to cover, and use that to figue out the precision in pieces of a second you are interested in.  (I got into this discussion with someone before, and they convinced me that 2^63 hundreths of a second is a LOONNNGGGGGG time.)