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 <[email protected]>
> System Integration Analyst (NOC Web Developer)
>
> -----Original Message-----
> From: Tim Bunce [mailto:[email protected]]
> Sent: Wednesday, September 21, 2011 9:45 AM
> To: Byrd, Brendan
> Cc: [email protected]
> 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: [email protected] [mailto:[email protected]] On Behalf Of Jeff Zucker
> > Sent: Tuesday, September 13, 2011 12:57 PM
> > To: [email protected]
> > Cc: Byrd, Brendan
> > Subject: Re: New NestedHash module needs home
> >
> > On Tue, Sep 13, 2011 at 7:50 AM, Jonathan Leffler
> > <[email protected]<mailto:[email protected]>> wrote:
> >
> > On Mon, Sep 12, 2011 at 10:29, Byrd, Brendan
> > <[email protected]<mailto:[email protected]>> 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
>
