Jens Rehsack wrote:
> Hi DBI and DBD developers,
>
> I have some open points for DBD::File I'd like to ask for feedback on them.
>
> The first two are related to the table meta data.
>
> 1) I introduced simple getters and setters for DBD::File table's meta
> data (look for get_file_meta and set_file_meta in
> lib/DBD/File/Developers.pod). Merijn and me came over to extend
> this interface with some wild cards:
> - '.': default - read, the attributes of the database handle is
> delivered/modified (even through a proxy, which was the
> primary intention)
> - '*': all - the attribute of all tables (and the default one)
> is modified
> - '+': as '*', but restricted to all ANSI conform tables names
> (default isn't touched)
> - qr//: all tables matching the regex are affected
I read Developers.pod and did not notice these wild cards but I'll
assume they are implemented and not documented as yet.
> The question is related to the getter: how should the attributes being
> returned (or more: what API should be supported)?
> Let me explain a bit deeper the cause of the question. set_file_meta
> can be called using the table_name as first argument, the attribute
> name as second one and the new attribute value as third argument.
> It sounds reasonable to allow following call, too:
>
> $dbh->func( $tname, { attr1 => val1, attr2 => val2 },
> 'set_file_meta' );
>
> Consequently get_file_meta should be able to return more than one
> attribute, shouldn't it? So we have 3 situations for get_file_meta
> regarding the expected return values:
> a) 1 table, 1 attribute - expected return value is a scalar
> b) n tables, 1 attribute - expected return value is a hash of
> table names pointing to the scalar value of the attribute
> belonging to that table
> c) n tables, m attributes - expected return value is a hash of
> table names pointing to a hash of attribute names containing
> the attribute values of the affected table
>
> I rate it to complex in API and need external thoughts :)
I never like APIs where you need to examine the result to know what sort
of result you have; I prefer to know up front what I'm going to get. In
that respect I presume (a) is ok since at most it can return the
attribute value or perhaps undef. (b) and (c) could be combined into
always returning:
{
table1 => {attr1 => value, attr2 => value},
table2 => {attr1 => value, attr2 => value},
.
.
}
Just a thought.
> 2) backward compatibility of depreciated structures per table of DBD::CSV,
> DBD::AnyData (and maybe later DBD::PO or DBD::DBM). DBD::CSV had a
> structure $dbh->{csv_tables}{$tname}{...} - which is now handled via
> $dbh->{f_meta}{$tname}{...} ... - DBD::AnyData had the same with
> $dbh->{ad_tables}{$tname}{...}.
> Both had several attributes in their which were not synchronized
> between both DBD's. Further, the $dbh->{f_meta} structure contains
> the table names after they walked through an internal filter
> (suggested by mje) which handles the identifier case. An additional
> structure $dbh->{f_meta_map} is used to hold the map between the
> original table name (from SQL statement or through the getter/setter)
> and the internal used identifier.
>
> Because it could be very difficult to manage backward compatibility
> there, I would like to have a solution which can be plugged in as
> early as possible:
> a) $dbh->{csv_tables} or $dbh->{ad_tables} should become a tied hash
> which access the table's meta data using the get_table_meta method
> from the table implementor class.
Sounds ok to me if you need that backwards compatibility.
> b) further, the meta data which can be accessed through this tie
> should be tied, too - to allow overriding FETCH/STORE methods which
> could handle the mapping between old attribute names and new
> attribute names.
If you want/need to go that far in maintaining compatibility.
How much code relies on these attributes - is it all possible to know?
> While I rate being 2a more important than 2b, I would like to get
> feedback for both ideas. Discarding 2a could result in inconsistent
> entries in $dbh->{f_meta} which could lead the DBD into unpredictable
> behavior.
> My third question has lesser implications :)
>
> 3) Merijn and me had the idea to let the users decide on connection
> whether to use DBI::SQL::Nano or SQL::Statement - not globally via
> DBI_SQL_NANO environment variable.
>
> Because of the handling of the handles for the dr, db and st
> instances of a DBD I hoped to get some suggestions how we could
> implement a similar behavior for DBD::File::Statement and
> DBD::File::Table.
Don't understand the question - sorry.
> Thanks for all answers in advance,
> Jens
>
>
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
