Features

LOCK TABLE

The newly implemented internal common table meta storage area would allow us to implement LOCK TABLE support based on file system "flock ()" support.

Transaction support

While DBD::AnyData recommends explicitly committing by importing and exporting tables, DBD::File might be enhanced in a future version to allow transparent transactions using the temporary tables of SQL::Statement as shadow (dirty) tables.

Transaction support will heavily rely on lock table support.

Data Dictionary Persistence

SQL::Statement provides dictionary information when a "CREATE TABLE ..." statement is executed. This dictionary is preserved for some statement handle attribute fetches (as "NULLABLE" or "PRECISION").

It is planned to extend DBD::File to support data dictionaries to work on the tables in it. It is not planned to support one table in different dictionaries, but you can have several dictionaries in one directory.

SQL Engine selecting on connect

Currently the SQL engine selected is chosen during the loading of the module DBI::SQL::Nano. Ideally end users should be able to select the engine used in "DBI->connect ()" with a special DBD::File attribute.

Other points of view to the planned features (and more features for the SQL::Statement engine) are shown in SQL::Statement::Roadmap.

Testing

Performance

To improve the performance of the underlying SQL engines, a clean re-implementation seems to be required. Currently both engines are prematurely optimized and therefore it is not trivial to provide further optimization without the risk of breaking existing features.

Join the DBI developers IRC channel at <irc://irc.perl.org/dbi> to participate or post to the DBI Developers Mailing List.

Reliability

duplicate table names

It is currently possible to access a table quoted with a relative path (a) and additionally using an absolute path (b). If (a) and (b) are the same file that is not recognized (except for flock protection handled by the Operating System) and two independent tables are handled.

invalid table names

The current implementation does not prevent someone choosing a directory name as a physical file name for the table to open.

Extensibility

DBD::Sys

Derive DBD::Sys from a common code base shared with DBD::File which handles all the emulation DBI needs (as getinfo, SQL engine handling, ...)

DBD::Dir

Provide a DBD::File derived to work with fixed table definitions through the file system to demonstrate how DBI / Pure Perl DBDs could handle databases with hierarchical structures.

DBD::Join

Provide a DBI driver which is able to manage multiple connections to other Databases (as DBD::Multiplex), but allow them to point to different data sources and allow joins between the tables of them:

  # Example
  # Let table 'lsof' being a table in DBD::Sys giving a list of open files using lsof utility
  # Let table 'dir' being a atable from DBD::Dir
  $sth = $dbh->prepare( "select * from dir,lsof where path='/documents' and dir.entry = lsof.filename" )
  $sth->execute(); # gives all open files in '/documents'
  ...

  # Let table 'filesys' a DBD::Sys table of known file systems on current host
  # Let table 'applications' a table of your Configuration Management Database
  #  where current applications (relocatable, with mountpoints for filesystems)
  #  are stored
  $sth = dbh->prepare( "select * from applications,filesys where " .
                       "application.mountpoint = filesys.mountpoint and ".
                       "filesys.mounted is true" );
  $sth->execute(); # gives all currently mounted applications on this host