Hi Tim,
regarding to our short discussion in #dbi about the future of SQL::Statement
and the implications to DBI::SQL::Nano here the open discussion for all.
I've want to improve SQL::Statement by design, that means I want to design
it from the basics using Design Patterns (especially the Command Pattern
and the Factory Pattern - and surely some more). The goal should be, to reduce
the amount of conditionals in the code and move them into polymorphism.
I want to start with a BNF based parser, which should be more extensible
and should allow translations into other dialects by design (to be able to proxy
parts of the requests to other Databases).
So far, so good - all this has no consequences and implications to
DBI::SQL::Statement, as the calling-interface remains (new, prepare, (bind,)
execute, ...).
But the tables API should be modified. We seen during the last updates, the
capabilities of some tables and the missing capabilities here and there that
the table API is much to weak. Further I want have extensions like column
renaming (ALTER TABLE, ...), indexes, triggers, cursors and a data dictionary
support.
Earlier versions of SQL::Statement and (current version of) DBI::SQL::Nano
support a table method named "fetch_one_row" - with a more or less
difficult calling convention to fetch a row with a specific primary key. But the
implementation lacked support for fetching specific rows when the expression
had q{WHERE pk_col IN ("foo","bar")} - indexes will solve that (and more).
I currently can't say how the concrete table API will look like, but I'm pretty
sure that it will be very incompatible to the current one. Cursor support will
be mandatory (ok, there could be a wrapper which had a hidden column
with an incremented integer) and data dictionary support, too.
I do not intend to create an API which forces a compatibility break. I can
imagine that it's possible to have a wrapper API between old API and the
new one in DBI::SQL::Nano::Table_ - but I can neither guarantee about it's
quality nor it's performance. The primary intention of DBI::SQL::Nano was
it's performance on selected operations - this will be no longer true in that
case. I cannot imagine to adapt DBI::SQL::Nano to support the new API
(currently, this might change and the entire discussion is worthless), so
we should thing about the options we have when SQL::Statement v2 is
coming.
We figured out those options in IRC:
1) DBI requires (or bundles) SQL::Statement and discards DBI::SQL::Nano
2) SQL::Statement v2 will be written in a way that allows to extract a basic
API (as SQL::Statement::Lite => DBI::SQL::Nano v2), but I'm not sure
how "lite" or "nano" this will be
3) Unbundle DBI::SQL::Engine and DBD::File (funny, two abstract
Meta-DBD's in CPAN jungle), but this will limit the tests of DBD::Gofer
4) We figure out a way to abstract the table in DBI::SQL::Engine (might
slow down the entire implementation ...)
Another option might be to unbundle the entire Meta-DBD stuff in an own
module/package which contains DBD::Gofer (and what ever is required
there, too), DBI::Sql::Engine, DBD::File, DBD::DBM ...
After you pointed me to
http://blog.timbunce.org/2010/07/16/java2perl6api-java-to-perl-6-api-tranalation-what-why-and-whereto/,
another idea came up in my stumble brain: if you're working on a DBI for Perl6,
maybe SQL::Statement v2 should be developed first for the Meta-DBD's there
and optionally backported later (or not, if "we" (you, Merijn, Martin,
who ever wants
participate in Meta-DBD development and myself) decide that we all can pretty
live with Perl6 DBI, DVD::CSV etc. modules).
As I also told on IRC, there is no reason to panic or quick decide anything or
react quickly, SQL::Statement v2 is at least 6 month away from the first line
of code and surely 9-12 month away from first semi-production release.
Best regards,
Jens
