I am preparing to add the ability to attach metadata to DBDs that
subclass DBD::File. This will mean that DBI metadata methods such as
primary_key() and column_info() will be available and also that other
modules like DBIx::Class and Class::DBI will have access to the metadata.
I've outlined my proposed interface below and would appreciate
comments. The short version is that if the user sets the
"f_use_metadata" database handle attribute, SQL::Translator will be used
to parse CREATE TABLE statements and the resulting object will be stored
serialized as YAML. When DBI metadata methods are called (and only
then), the YAML file will be queried.
=pod
=head1 New DBD::File driver-private attribute
=head2 f_use_metadata
0 : don't use any metadata (default)
1 : use SQL::Translator to handle metadata
* If set to true, dies unless SQL::Translator is available
=head2 f_sqlt_flags
* a hashref of flags to be passed to SQL::Translator
* these shouldn't be needed for most uses
=head1 New DBD::File driver-private methods
=head2 f_create_metadata( $create_table_sql )
* parses DDL with SQL::Translator
* saves YAML-serialized SQL::T object in $table_name.yml
* if f_use_metadata is true, this method is called implicitly during
execute() of CREATE TABLE statements; for TEMPORARY tables, the
save-as-YAML step is skipped and the SQL::T object is stored in memory
* the method may also be called explicitly to attach metadata to an
existing table
=head1 column_info() and other DBI metadata methods
=head2 when f_use_metadata is false
* the DBI methods will return whatever (usually non-helpful)
information the DBD currently returns
=head2 when f_use_metadata is true
* the SQL::T object for the table is retrieved from the YAML file or,
for TEMPORARY tables, from memory
* dies if no SQL::T object is found
* otherwise queries the object and returns metadata information to DBI
=cut
--
Jeff
