Re: DBI v2 - The Plan and How You Can Help
RE: Placeholders: since DBIv1 already supports both forms of PH's, I see no reason to deprecate or abandon either form. Furthermore, to my knowledge, none of (ODBC, JDBC, ADO.NET) has abandonded or deprecated the ? form, so I don't see the need for DBI to. RE: LOBs and "SQL Parse Trees": having recently implemented LOB support for a JDBC driver (and soon for a DBD), I can assure you that SQL parse trees are unneeded to support them. For databases robust enough to support LOBs, they'll almost always provide sufficient metadata info and/or SQL syntax to manipulate them; only databases which don't support LOBs have that difficulty. Furthermore, a quick review of the current DBI will indicate that Mssr. Bunce has already implemented some stub methods for generalized support. RE: SQL Parse Trees (or other non-SQL query input) Since none of (ODBC, JDBC, ADO.NET) seems compelled to impose this concept on driver writers, I don't see why DBI should be the vanguard. However, implementing a subclass of DBI to support it seems technically feasible, so I'd suggest that those of you championing this requirement implement one on DBI v1. Feel free to use DBIx::Chart to bootstrap your project. As the proponents of this notion are so generous with their requirements for those of us who develop DBI drivers and/or contribute development efforts to the DBI itself, I'm sure they won't object if I provide a few requirements: 1. For DBI drivers which support them, your subclass must support - arbitrary numbers and levels of JOINs (including various outer, and non-equijoins) - arbitrarily nested subqueries (including correlated) - HAVING and GROUP BY clauses - ORDER and LIMIT clauses - updatable cursors - database-specific SQL extensions 2. It must function with current versions of 40% of DBD's created or updated on CPAN since Jan. 1, 2003. Said 40% must include - DBD::ODBC - DBD::Oracle - DBD::Pg - DBD::MySQL - DBD::CSV - one 'exotic' driver (e.g., DBD::iPod or DBD::Amazon, but excluding DBD::Google, whose syntax is too simplistic for a meaningful test) (FWIW: Past experience (e.g., execute_array()) leads me to believe Mssr. Bunce's requirements are likely much higher than 40%, so "choose wisely, grasshopper") BTW: If you need a list of DBD's meeting said requirement, let me know, I just pulled one down. 3. It cannot require any changes to either DBI or the selected DBD's. 4. It must produce a database-independent conforming set of error codes (feel free to use SQLSTATE aka $h->state) 5. It must be uploaded to CPAN, and list, and demonstrably function against, the DBD's selected in requirement (2) above. Once you've implemented the subclass, you'll have empirical proof of the feasibility, and, more importantly, you'll be able to port the subclass to DBIv2, without any additional burden on DBI developers. Regards, Dean Arnold Presicient Corp.
Re: DBI v2 - The Plan and How You Can Help
BTW: If you need a list of DBD's meeting said requirement, let me know, I just pulled one down. Sure, send it over. [ ] DBD-ADO-2.94.tar.gz 31-Jan-2005 02:4041k GZIP compressed docume> [ ] DBD-ASAny-1.13.tar.gz 31-Oct-2003 15:0030k GZIP compressed docume> [ ] DBD-Amazon-0.10.tar.gz 23-May-2005 15:4158k GZIP compressed docume> [ ] DBD-AnyData-0.08.tar.gz 19-Apr-2004 03:1620k GZIP compressed docume> [ ] DBD-CSV-0.22.tar.gz 31-Mar-2005 18:0636k GZIP compressed docume> [ ] DBD-Chart-0.81.tar.gz 26-Jan-2005 19:59 212k GZIP compressed docume> [ ] DBD-DB2-0.78.tar.gz 19-Sep-2004 10:3475k GZIP compressed docume> [ ] DBD-File-0.34.tar.gz21-Jun-2005 01:14 8k GZIP compressed docume> [ ] DBD-Google-0.11.tar.gz 04-Mar-2004 18:5120k GZIP compressed docume> [ ] DBD-Informix-2005.01..> 14-Mar-2005 19:01 267k GZIP compressed docume> [ ] DBD-Ingres-0.51.tar.gz 12-Jan-2004 06:1846k GZIP compressed docume> [ ] DBD-InterBase-0.43.t..> 25-Feb-2004 04:3078k GZIP compressed docume> [ ] DBD-LDAP-0.06.tar.gz12-Mar-2004 21:4825k GZIP compressed docume> [ ] DBD-Log-0.22.tar.gz 27-May-2005 06:5114k GZIP compressed docume> [ ] DBD-MaxDB-7_5_00_26...> 18-Apr-2005 08:3879k GZIP compressed docume> [ ] DBD-Mimer-1.00.tar.gz 25-Nov-2003 15:5171k GZIP compressed docume> [ ] DBD-Mock-0.27.tar.gz11-Jul-2005 11:3634k GZIP compressed docume> [ ] DBD-Multiplex-1.96.t..> 25-Jan-2005 17:30 9k GZIP compressed docume> [ ] DBD-ODBC-1.13.tar.gz08-Nov-2004 10:1595k GZIP compressed docume> [ ] DBD-Oracle-1.16.tar.gz 22-Oct-2004 05:17 230k GZIP compressed docume> [ ] DBD-Pg-1.43.tar.gz 23-Jun-2005 08:09 128k GZIP compressed docume> [ ] DBD-PgPP-0.05.readme09-May-2004 08:06 3k [ ] DBD-PgPP-0.05.tar.gz13-May-2004 12:5616k GZIP compressed docume> [ ] DBD-PgSPI-0.02.tar.gz 06-Dec-2004 00:3021k GZIP compressed docume> [ ] DBD-Redbase-0.22.tar.gz 21-Oct-2003 22:5128k GZIP compressed docume> [ ] DBD-SQLite-1.09.tar.gz 20-Jun-2005 11:42 464k GZIP compressed docume> [ ] DBD-SQLite2-0.33.tar.gz 10-Sep-2004 11:50 355k GZIP compressed docume> [ ] DBD-Sprite-0.56.tar.gz 12-Jun-2005 21:5286k GZIP compressed docume> [ ] DBD-Sybase-1.05.tar.gz 19-Dec-2004 05:01 183k GZIP compressed docume> [ ] DBD-TSM-0.04.readme 22-Mar-2005 16:05 2k [ ] DBD-TSM-0.04.tar.gz 23-Jun-2005 16:32 9k GZIP compressed docume> [ ] DBD-Teradata-1.20.ta..> 17-Sep-2004 19:2736k GZIP compressed docume> [ ] DBD-Trini-0.01.tar.gz 15-Jul-2003 03:1821k GZIP compressed docume> [ ] DBD-Unify-0.31.tgz 16-Mar-2004 11:0731k GZIP compressed tar ar> [ ] DBD-XBase-0.241.tar.gz 21-Nov-2003 09:25 109k GZIP compressed docume> [ ] DBD-Yaswi-0.01.tar.gz 21-Feb-2005 19:46 4k GZIP compressed docume> [ ] DBD-iPod-0.01.tar.gz06-Jan-2005 02:4113k GZIP compressed docume> [ ] DBD-mysql-3.0002.tar.gz 11-Jul-2005 12:49 127k GZIP compressed docume> [ ] DBD-mysql-AutoTypes-..> 02-Mar-2004 06:03 3k GZIP compressed docume> [ ] DBD-mysql-SimpleMySQ..> 28-Apr-2004 16:39 4k GZIP compressed docume> [ ] DBD-mysqlPP-0.04.tar.gz 24-Jan-2003 06:14 7k GZIP compressed docume> - Dean
Re: DBI v2 - The Plan and How You Can Help
Tim Bunce wrote: And nobody mentioned JDBC as a potential model. Odd that. I was sorely tempted to do so (and did mention it a few times in my posts, along w/ ODBC and ADO.NET), but there are some things about JDBC which rub me the wrong way (e.g., explicit set/get methods for every data type; no true binding support; the lame "bulk" interface; etc.). I'm not crazy about all the DataSource business, either. But the threading support, the Factory pattern presented by Statement classes, the nice separation of metadata from statements/resultsets/connections, and XA would certainly be nice models to follow. One area of concern I have is the ability to subclass. I've been struggling w/ trying to subclass+extend JDBC the same way I subclass DBI for some things, and haven't found any app-neutral solutions just yet (trying to wrap another JDBC driver and expose its driver specific methods seems to require a lot of extra heavy lifting). Still, I'm sure things will liven up once I've put an initial sketch together... Tim. Dean Arnold Presicient Corp.
Re: DBI v2 - The Plan and How You Can Help
Richard Nuttall wrote: - support for automatically pulling database DSN information from a ~/.dbi (or similar) file. This is constantly re-invented poorly. Let's just do a connect by logical application name and let the SysAdmins sort out which DB that connects to, in a standard way. This reminds me one one thing I hate about DB access, and that is having the DB password stored in plain text. Of course there are ways to provide some concealment, but nothing particularly good or integrated into the access. If the "connecting by logical application name" could also include some level of security access, that would be a big improvement. R. Which is why major DBMSs are increasingly relying on SSO based solutions. (e.g., Kerberos/LDAP authentication). Not certain if DBI is the proper level to implement that, (probably needs to be down at the DBD <=> DBMS level). And "in a standard way" may still be wishful thinking. Also, I'm not sold on the idea that a ~/.dbi file is particularly secure in that regard. Not neccesarily opposed, just not convinced its the right solution. (I don't like cleartext passwords either, but due to the variance in DBMS's authentication methods, I don't know if DBI can solve that problem). - Dean