I currently have a working and tested model for a "nested hash to table" conversion. This will essentially fill the gap for DBD::AnyData to be able to convert nested array/hash objects, instead of merely a single table inside of an array. It works by a recursive sub that looks through the tree, using hash keys for column/table names, and arrays as grouping tables. The result is a flatten version of the tree, close to 4NF in most cases, with a naming scheme that should match the subject matter.
This flattened hash is then added into a DBI object, using multiple DBD::AnyData import calls. This would work for JSON objects, complex XML trees (if compiled into a Perl object), Moose classes, or any Perl object with a "sane" structure. I have attached a standalone example of the code in action. My dilemma is: Where exactly should this kind of module go in the CPAN namespace? There's a number of potential choices that I see: AnyData::Format::NestedHash - This would provide functionality for non-DBI structures, as well as tie into DBD::AnyData as a new data type. The problem is that AnyData's entire model is designed around single tables, not multiple tables. Tying this module into AnyData would require some re-writes or special exceptions in place to be able to look at multiple tables for one object. DBD::AnyData::Format::NestedHash - Since DBD::AnyData is a bit more familiar with multiple tables, maybe a new section could be created here? However, DBD::AnyData's namespace is actually rather small, as it uses AnyData for most of its conversions. Furthermore, the functionality within the dbi:AnyData subs are all tied to single tables again, including the DBI interactions. DBD::NestedHash - This could also be its own Perl module within CPAN. However, the hash to table conversion is such a thin wrapper around DBD::AnyData that it just seems to make more sense to actually tie it into that module somehow, so that developers can benefit from the integration. Those are the pros/cons I see. Since you guys are the developers for the namespaces mentioned, I figured I should leave the question to you. Are there any new development directions for any of these modules that would provide a better fit for this one? Or is a standalone module truly the best route? -- Brendan Byrd <byr...@insightcom.com<mailto:byr...@insightcom.com>> System Integration Analyst (NOC Web Developer)
json.pl
Description: json.pl
