www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DBI Interface 0.1.5

reply Jeremy Cowgar <jeremy __no__spAM__cowgar.com> writes:
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/
Apr 20 2005
next sibling parent reply pragma <pragma_member pathlink.com> writes:
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
Apr 20 2005
parent reply Jeremy Cowgar <jeremy __no__spAM__cowgar.com> writes:
 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/
Apr 20 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
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/
Apr 20 2005
prev sibling next sibling parent reply novice2 <novice2_member pathlink.com> writes:
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/
Apr 20 2005
parent reply Jeremy Cowgar <jeremy __no__spAM__cowgar.com> writes:
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
Apr 21 2005
next sibling parent reply novice2 <novice2_member pathlink.com> writes:
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.
Apr 21 2005
parent Jeremy <jeremy nospam.nospam.cowgar.com> writes:
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
Apr 21 2005
prev sibling next sibling parent pragma <pragma_member pathlink.com> writes:
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
Apr 21 2005
prev sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
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.)
Apr 21 2005
parent "Jason King" <jhking airmail.net> writes:
 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.)


Either Unix epoch (1/1/1970) or 1/1/1900 would be dates that have 
a lot of existing software support.  1/1/1999 is a problem if 
we're storing birthdates for anything besides summer-camp.
Apr 10 2014
prev sibling parent reply Jeremy Cowgar <jeremy AT NOSPAM cowgar DOT com> <Jeremy_member pathlink.com> writes:
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/


With the help of http://dsource.org, D DBI now also has a forum area for
discussion. If you have comments, ideas or suggestions, please contribute your
ideas in the forum area on http://www.dsource.org/forums/viewforum.php?f=60
where  it's easy to discuss different ideas and ensure everyone is heard and the
decisions made make it into the code.

Thanks!

Jeremy Cowgar
http://jeremy.cowgar.com/ddbi/
http://www.dsource.org/forums/viewforum.php?f=60
Apr 26 2005
next sibling parent " FrankLike" <1150015857 qq.com> writes:
Hi,Jeremy Cowgar


 http://jeremy.cowgar.com/ddbi/
 http://www.dsource.org/forums/viewforum.php?f=60


I have visited the http://jeremy.cowgar.com/,ddbi is very good,do 
you want to go on?

Thank you.

  FrankLike
Apr 10 2014
prev sibling parent reply "Jason King" <jhking airmail.net> writes:
One other nag (suggestion).  Keep your base DBI and any object 
relational wrapper separate.  A lot of use-cases don't need ORM, 
and separating the two parts means that adding a new db driver is 
simply a matter of plugging in the dbi part.
Apr 10 2014
parent "Dylan Knutson " <tcdknutson gmail.com> writes:
On Friday, 11 April 2014 at 00:01:45 UTC, Jason King wrote:

 One other nag (suggestion).  Keep your base DBI and any object 
 relational wrapper separate.  A lot of use-cases don't need 
 ORM, and separating the two parts means that adding a new db 
 driver is simply a matter of plugging in the dbi part.


Am I going crazy here? Multiple people are responding to a thread
that was last active in 2005.
Apr 10 2014