Hi, as some people from #dbi channel on irc.perl.org know, I'm currently working on updating DBD::AnyData to work properly with recent DBD::File updates.
AnyData and DBD::AnyData were born in year 2000 - and the design didn't changed since birth. But DBD::File got some rework - thanks to Tux (H. Merijn Brand), mje (Martin Evans) and myself. The further development of SQL::Statement brakes at least DBD::DBM - so we did some refactoring (and test extension) to detect such breakage earlier next time. Without blaming anyone: AnyData implements the whole DBD::File (state of yr 2000) and DBD::AnyData is more or less misusing the DBD::File infrastructure to provide an DBI interface to AnyData. My current intention is to rework AnyData and DBD::AnyData to have clear responsibility which tasks are done at which place in the code. This is somewhat difficult, because there are no use cases or tests for AnyData (or DBD::AnyData) giving full study-able examples. I decided to reduce the functionality of AnyData - to have a module which finally does exactly what is required - without providing helper functions for a dozen of foreign modules. But this is more difficult than expected: AnyData provides remote file access (which must be provided by DBD::File, too when we want to keep all functionality). AnyData mixes a lot of functionality and re-implements a lot which is already provided by other modules. This leads me finally to go just one more step back: I should define responsibilities in AnyData (keeping DBD::AnyData and DBD::File in mind) for the parser modules, for the storage modules and for the controller. I think, the adTie (), adTable () functions provide some kind of views - something which should be provided from somewhere else - not from the AnyData.pm itself. Further, I think, either the "storage" represented by DBD::File::Table should be usable by AnyData (maybe DBD::AnyData could provide an adapter) or DBD::File should be able to use pluggable storage backends, too. Of course, another way could be to extract the SQL-engine interface from DBD::File into a DBI::DBD::SqlEngine and DBD::AnyData uses that without caring of DBD::File (for some time until we could do better). I have some additional tasks to do where I need to write some more modules and update some of those I currently have. And I have a time limit for that tasks which means, I can't play for month with DBD::AnyData. That's why I ask: would it be very bad when DBI-1.612 would break DBD::AnyData for a limited amount of month (3-5) or should I (we?) investigate more effort to get a clean, running AnyData and DBD::AnyData out there with DBI-1.612? Best, Jens
