At 6:30 PM -0700 7/11/05, Dean Arnold wrote:
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.
I should emphasize that I never expected to be able to send any type
of ASTs over the pipe to the database. They would still be
interpreted by the database driver for Perl and/or a wrapper thereon,
into the database native format. Its just that, to an application,
it would appear that the ASTs were going over the pipe, as to their
effect, even though they weren't behind the scenes.
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.
I agree. Already in progress. In a week or two I should announce
"Rosetta/SQL::Routine Developer Preview #3" and look forward to
people trying it out and giving me the usual "how do I" questions.
But wait until then before making any in-depth analysis, since I have
some large updates to post first.
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:
I agree.
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
Rosetta supports the definition of all of the above right now, except
that the last 2 are incomplete (for now). I still have to add "the
last mile", which is joining the definition to the implementation,
though that is what DR3 is for. See the top of
SQL::Routine::Language for a summary of what I claim to support.
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)
My expectation is to support all DBDs that are themselves known to
work under the newest Perls and DBIs. Databases that already support
a feature when it is invoked as a SQL string will be supported for
that feature by Rosetta prior to those that don't and for which the
features need to be emulated.
BTW: If you need a list of DBD's meeting said requirement, let me know,
I just pulled one down.
Sure, send it over.
3. It cannot require any changes to either DBI or the
selected DBD's.
Yes.
4. It must produce a database-independent conforming set of error codes
(feel free to use SQLSTATE aka $h->state)
Already done, though the current list of codes is short and pending updates.
5. It must be uploaded to CPAN, and list, and demonstrably function against,
the DBD's selected in requirement (2) above.
I can only personally test against databases that are easy to install
on Mac OS X 10.3.9 and are free-as-in-beer (eg, SQLite, MySQL); for
others, I will need assistence to prove that they work.
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.
I accept your challenge.
-- Darren Duncan
