(Disclaimer) I use this post half as an announcement and half as a feedback base for users.

Some time ago, jZed (Jeff Zucker) gave me the maintainership of DBD::AnyData in common with SQL::Statement and AnyData. I share the maintainership of DBD::CSV, DBD::DBM and DBD::File with Tux (H. Merijn Brand).

While I concentrated my effort on SQL::Statement, Merijn concentrates on DBD::CSV (with some DBD::File). Last but not least this results in an ugly issue in DBD::DBM discoverd by Birmingham.pm.

After that we increased our effort on DBD::File and DBD::DBM with the result, that many things were missing in DBD::DBM (related to SQL::Statement) and DBD::File needs to be rebased for proper working with DBI::SQL::Nano and SQL::Statement again.

This heavy refactoring requires updates of all DBD::File based DBI drivers - thus DBD::AnyData, too. To be true, I hoped I can ignore it a while longer, but it's impossible. Upcoming DBI will break DBD::AnyData 0.09 - so I can't wait anymore.

(Facts): DBD::AnyData has documented a lot of things which are (no longer) true - e.g. the requirement of $dbh->func. Got versions of DBD::DBM, DBD::CSV and DBD::AnyData implements a lot of methods for the same thing slightly different. For DBD::CSV and DBD::DBM, this is harmonized in DBD::File. I plan to do the same for DBD::AnyData.

Now the questioning part begins. The implementation of DBD::AnyData extension for older DBD::Files conflicts with the new ones. My current intention is rewriting the interface and throw away the old code (at least unmaintained for 4 years). This would break any existing application running with DBD::AnyData 0.09 and below - but gives a good starter for new ones.

While I don't intend to break code for fun, I will try of course to keep as close to the current API as I can. On the other hand, keeping close but not exact could create scary issues.

While any application which shall use DBD::AnyData 0.10 or higher needs to be patched for the new API, wouldn't it makes sense to create the new API closer to the common source and reworked DBD::File design? This would reduce the risk of later issues of breaking API again (to put things to an awful end than to perpetuate an awful time).