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

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

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

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.

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.