Re: DBI v2 - The Plan and How You Can Help

2005-08-16 Thread Dean Arnold

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

2005-07-12 Thread Dean Arnold

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

2005-07-12 Thread Dean Arnold

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

2005-07-04 Thread Dean Arnold

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