I think I'm going to end up going the route of a new module called DBD::Object. While AnyData seems like a good fit, the whole table vs. database thing seems to hamper that choice too much. Besides, if we're talking about multiple tables, it's pretty much a database at that point, anyway.
FYI, I'm also (simultaneously) working on a few other DBI modules that you guys might be interested in: DBD::SNMP - This will be a merging between the Net-SNMP module (for OID data) and the Net::SNMP/::XS module (for everything else), with built-in multi-device support (via a virtual temp table). If David doesn't hurry up and get those dispatch patches in, I guess they will be included here, too. DBD::FusionTables - Interaction with Google's Fusion Tables API, which has a SQL interface. And when I say SQL interface, I mean a really stripped-down bare-bones SQL interface. Still, it can do INSERTs, SELECTs, UPDATEs, etc., so let's build an interface and see if it even works on DBIC. SQL::Statement::Functions::CAST - This is what happens when I say (for the thousandth time) "Oh, that should be an easy function to implement!" Then I buried my head in SQL-99 specs and the madness began. I am making good headway on this one, though. Depending on what other SQL-99/ODBC functions are already in Perl, it may just turn into ::SQL99 to implement mostly everything. From: dub...@gmail.com [mailto:dub...@gmail.com] On Behalf Of Jeff Zucker Sent: Tuesday, September 13, 2011 12:57 PM To: dbi-dev@perl.org Cc: Byrd, Brendan Subject: Re: New NestedHash module needs home On Tue, Sep 13, 2011 at 7:50 AM, Jonathan Leffler <jonathan.leff...@gmail.com<mailto:jonathan.leff...@gmail.com>> wrote: On Mon, Sep 12, 2011 at 10:29, Byrd, Brendan <byr...@insightcom.com<mailto:byr...@insightcom.com>> wrote: > I currently have a working and tested model for a "nested hash to table" > conversion. [...] > > ** ** > > *AnyData::Format::NestedHash - *[...] > > *DBD::AnyData::Format::NestedHash - *[...] > > *DBD::NestedHash - *[...] > I'm not sure it fits there; it may be more driver-related than built atop DBI. But you didn't mention the DBIx namespace... It sounds to me like it fits very well in the AnyData/DBD::AnyData namesapce because it would provide a driver for using DBI against things not usually considered to be databases. Although I gave birth to the AnyDatas, I'm not very involved in them at the moment so if you go that route, you should check with Jens Reshack who currently is the primary maintainer. -- Jeff
