- 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

Reply via email to