- optional treatment of the statements as an AST, similar in concept to
SQL::Routine, or Tangram::Expr. Death to SQL templating systems!
I suspect during this process people are going to want a lot of things
that layer on top of what we currently see as DBI.
Personally I think Tim got it right to initially only handle
connectivity and preparation stuff in DBI, and not try to deal with
schemas or relational-mapping or any of that other gumpf.
I see the issues with the table methods in DBI as an example of this.
What you want in many situations is something much more details that
just a list of table names.
So with that in mind.
I'd like to see DBI done as a set of multiple interfaces that each
driver can choose to support or not support.
For example, the connectivity layer. This currently works very very well
and has allowed huge numbers of different interfaces to almost every
database in existance.
Every driver, as they do now, should implement support for this layer.
On top of that, if you really must interact with the database to query
table names and so on, lets see that done as a separate layer.
DBI2::Schema or something. drivers could then specifically advertise
support or non-support for that API.
And we could get an interface somewhat richer than the current "raw
hashes" one.
Adam K
