On Wed, Sep 21, 2011 at 03:17:53PM +0000, Byrd, Brendan wrote: > > It basically takes whatever Perl tree object you throw at it and turns > it into a database.
Cool. Given that description I'd suggest a name like DBD::TreeData<Mumble> e.g., DBD::TreeDataWrapper with tdw_ as the prefix. Tim. > This is achieved with a custom recursive sub to > normalize the tree, and a thin wrapper around DBD::AnyData to dump the > tables via ad_import. > $dbh = DBI->connect('dbi:Object:', undef, undef, { > obj_object => JSON::Any->jsonToObj($json), > obj_prefix => 'json', > obj_1st_table_name => 'map_routes', > obj_table_rename => { > 'html_instructions' => 'instructions', > 'southwests' => 'sw_corners', > 'northeasts' => 'ne_corners', > }, > }); > > I'm a stickler for details, so this will probably end up with the full gambit > of ODBC variables and *_info subs. (Just processed that for > DBD::FusionTables::GetInfo; man, that's a mess of 185 different bitmaps...) > > As far as the name, I was going to use NestedHash, but it does work off of > both Arrays and Hashs (as well as looks at other ref types), so I figured > something generic would work better. Technically, it would work for any Perl > "object", even a single hash. Some potential names could be: > > DBD::Object > DBD::Tree > DBD::TreeObject > DBD::NestedObject > > Which one would work best? > > -- > Brendan Byrd <byr...@insightcom.com> > System Integration Analyst (NOC Web Developer) > > -----Original Message----- > From: Tim Bunce [mailto:tim.bu...@pobox.com] > Sent: Wednesday, September 21, 2011 9:45 AM > To: Byrd, Brendan > Cc: dbi-dev@perl.org > Subject: Re: New NestedHash module needs home > > Would it be an actual DBI driver? > > Could you post some examples or docs? > > I'm uncomfortable with it having such a generic name. > Two words after the DBD would be better. > > Tim. > > On Wed, Sep 21, 2011 at 02:58:09AM +0000, Byrd, Brendan wrote: > > 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 >