At 12:35 AM -0700 7/9/05, Jonathan Leffler wrote:
I dunno which DBMS support prepare without a database connection, but I would expect all the mainstream databases to require a database connection. IBM DB2 does; IBM Informix Dynamic Server (IDS) does; someone else commented on this and said Oracle does; I would expect both Sybase and MS SQL Server to need the DB connection too. Probably PostgreSQL; not sure about MySQL. The only systems that might not need the DB connection are those that aren't using a separate SQL-based database server.
See my subsequent email/s where I left prepare() requiring an open database connection, and a separate function (for example, 'compile'), is split out and handles any prep work that can be done without an open connection.
Since you mention that some systems don't have the separate SQL-based database server, there are indeed some drivers that can take advantage of a separate 'compile' then, so they benefit from a split; the worst that happens with the others is a no-op. Some drivers gain, and no one loses anything.
I'm also far from convinced that there's any significant benefit in separating the 'create a database handle' from the 'connect to database server' part. The overhead of creating the handle - as distinct from make the connection to the DBMS - is negligible. There's nothing of any significance that can be done with the unconnected handle either - at least, for the mainstream SQL DBMS. So, the pre-fork creation of an unconnected handle provides negligible savings. Similar comments apply to the statement handles - in IDS, at any rate, there's nothing useful that can be done for statements until you've got a database handle. Or, at the least, you'd be moving away from the ODBC paradigm, and the ESQL/C paradgm too.
A main benefit of separating out the handle creation and database connection is the secondary effect whereby you can pre-associate statement handles with it that are expensive to create, such as because they generate SQL. Generating SQL and other such things is separate from the database and the speed advantage from separating this out as I described is not lost by the fact of what database servers don't support, since the databases are never given that work.
A primary effect benefit is any time you want to open the same connection more than once; you can configure it once when making the handle, and not again no matter how many times you open/close/open the connection, or re-open a connection that dies. Moreover, every open from the first to subsequent ones are done in the same way.
Certainly, one can make a DBI wrapper that adds some of those advantages, but given their simplicity and universal desirability, its better to build them in; any addition of complexity over the current DBI is negligible, or it may in fact be less complex than the current DBI.
As a general comment on DBI v2; we need to beware of the second-system effect (Brooks "Mythical Man Month"). In particular, the DBI must not mandate impossible levels of support from the drivers. It will benefit you nothing if the DBI is immaculate and wonderful and incredibly all-singing and all-dancing, but no-one can write a driver for it because the requirements cannot be met by the actual DBMS that Perl + DBI needs to work with.
What you say is fair enough, but I never proposed anything impossible or difficult; everything that I am proposing here is easy and simple.
-- Darren Duncan
