Re: DT::F::DBI docs
On 20 Jul 2003 22:53:00 +0200, Claus Färber [EMAIL PROTECTED] wrote: Tim Bunce [EMAIL PROTECTED] schrieb/wrote: The DBI has a (currently private) method to determine the underlying database type. It was borrowed from DBIx::AnyDBD. Take a look at _dbtype_names() in DBI.pm Yeah, I just updated DT::F::DBI to use that function. I intend to extend it to use $dbh-get_info(17); (=SQL_DBMS_NAME), and give it a public api, in the medium term. One of the problems I can see is that it just returns the type ODBC returns, which is already a problem for MySQL (returns /^mysqld-.*/[1]) That is an issue. But that's part of the reason why _dbtype_names() returns an ordered list. For mysqld-foo-bar it may return something like (mysqld-foo-bar, mysqld-foo, mysqld). and PostgreSQL (returns 'PostgreSQL', not 'Pg'[1]). I'm not sure what DBD::PgPP and DBD::PgSPI return, either. Maybe DBI::_dbtype_names should normalise these DBMS names (e.g. to the corresponding DBD::* driver name, if one exists). More likely that the DBI would supply a module that provides mapping between the sets of names. BTW, is there a CVS server for DBI somewhere? No. One day... Tim. Claus [1] I have only looked at unixODBC's source code and not installed it, so I might be wrong there.
Re: DT::F::DBI docs
Tim Bunce [EMAIL PROTECTED] schrieb/wrote: The DBI has a (currently private) method to determine the underlying database type. It was borrowed from DBIx::AnyDBD. Take a look at _dbtype_names() in DBI.pm Yeah, I just updated DT::F::DBI to use that function. I intend to extend it to use $dbh-get_info(17); (=SQL_DBMS_NAME), and give it a public api, in the medium term. One of the problems I can see is that it just returns the type ODBC returns, which is already a problem for MySQL (returns /^mysqld-.*/[1]) and PostgreSQL (returns 'PostgreSQL', not 'Pg'[1]). I'm not sure what DBD::PgPP and DBD::PgSPI return, either. Maybe DBI::_dbtype_names should normalise these DBMS names (e.g. to the corresponding DBD::* driver name, if one exists). BTW, is there a CVS server for DBI somewhere? Claus [1] I have only looked at unixODBC's source code and not installed it, so I might be wrong there. -- http://www.faerber.muc.de
Re: DT::F::DBI docs
On Wed, Jul 16, 2003 at 01:58:37AM -1000, Joshua Hoblitt wrote: Well, there are only two modules: DT::F::MySQL and DT::F::Pg. I'd really like to see a lot more database formatters. I'm willing to do DT::F::DB2. That still leaves several major DB's unsupported: Oracle SQL Server Sybase And all the minors: mSQL SQLite InterBase Pheonix SAPs DB Access??? Plus several more I didn't list. Anyone feel like volunteering? A couple months ago, I volunteered to do Oracle, if no one else had already started it: http://nntp.x.perl.org/group/perl.datetime/2494 I'm still willing to do that, but I don't know when. I'd prefer to do it at work, since I don't use Oracle anywhere else. However, I don't know whether or not my management will support me. I'm working on getting that support, but I'm getting impatient. In case that doesn't work out, does anyone know how I can access Oracle databases at home for free? ;^) -J Dave
Re: DT::F::DBI docs
Well, there are only two modules: DT::F::MySQL and DT::F::Pg. I'd really like to see a lot more database formatters. I'm willing to do DT::F::DB2. That still leaves several major DB's unsupported: Oracle SQL Server Sybase And all the minors: mSQL SQLite InterBase Pheonix SAPs DB Access??? Plus several more I didn't list. Anyone feel like volunteering? -J --
Re: DT::F::DBI docs
On Wed, 16 Jul 2003, Joshua Hoblitt wrote: Pheonix First of all, it's Phoenix, and second of all, you're thinking of Firebird. Don't get that name wrong or they'll come down on you like a ton of bricks ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DT::F::DBI docs
Joshua Hoblitt schreef: Well, there are only two modules: DT::F::MySQL and DT::F::Pg. I'd really like to see a lot more database formatters. snip 10 other databases Do all of these have different datetime formats? If database X has the same formats as e.g. Pg, it doesn't need a separate format. Of course DT::F::DBI should know about these cases. Should there be a default format DT::F::SQL for DT::F::DBI? (I don't know if SQL defines a date format, so I don't know if this is possible.) Eugene P.S. Anyone interested in DateTime::Format::CSV?
Re: DT::F::DBI docs
First of all, it's Phoenix, and second of all, you're thinking of Firebird. Don't get that name wrong or they'll come down on you like a ton of bricks ;) Your right - I'd been traveling for 24 hours. :) -J --
Re: DT::F::DBI docs
Joshua Hoblitt schreef: Do all of these have different datetime formats? If database X has the same formats as e.g. Pg, it doesn't need a separate format. Of course DT::F::DBI should know about these cases. If X has identical date/time handling as Pg I'd like to see DT::F::X be isa DT::F::Pg. Otherwise things might get a bit confusion for end users. Hmmm. I count 47 different DBD modules. That means 47 DT::F modules? (You're right about the confusion. Unless we could train end users to trust DT::F::DBI. The Perlmonks discussion that prompted this thread started when an end user made the 'mistake' to look only at DT::F::DBI, and not at the MySQL module, so it _is_ possible...) Eugene
DT::F::DBI docs
There was a recent thread out on perlmonks regarding the functionality of DT::F::DBI: http://www.perlmonks.org/index.pl?node_id=274054 Basically the user did not realize they were dealing with a factory and that the API was actually documented, in their case, in DT::F::MySQL. Perhaps a note in the docs saying for more information see the documentation for the class pertaining to your particular dbh... Or is this supposed to be polymorphic behavior, with all the db format classes sharing the same API...in which case the API should then appear in the main docs? Cheers, Matt
