Re: New NestedHash module needs home
Tim Bunce <[email protected]>
| Newsgroups | gmane.comp.lang.perl.modules.dbi.sybase.devel |
|---|---|
| Message-ID | <[email protected]> |
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
>