Depends on your definition of "actual". Or for that matter, your definition of
"Object".
I have some draft code on the beginning of this thread. It basically takes
whatever Perl tree object you throw at it and turns it into a database. 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. So it would
indeed be a DBI object. I would even tie it to the standard DBD driver code,
so that the traditional DBI->connect string would work. For example:
$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
