RE: New NestedHash module needs home
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.commailto:jonathan.leff...@gmail.com wrote: On Mon, Sep 12, 2011 at 10:29, Byrd, Brendan byr...@insightcom.commailto: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
Re: New NestedHash module needs home
On Mon, 12 Sep 2011 17:29:57 +, Byrd, Brendan byr...@insightcom.com wrote: DBD::NestedHash - This could also be its own Perl module within CPAN. However, the hash to table conversion is such a thin wrapper around DBD::AnyData that it just seems to make more sense to actually tie it into that module somehow, so that developers can benefit from the integration. Feel free to loan/borrow/steal from my Tie::Hash::DBD, which supports nested hashes using a serializer -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.14 and porting perl5.15.x on HP-UX 10.20, 11.00, 11.11, 11.23 and 11.31, OpenSuSE 10.1, 11.0 .. 11.4 and AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
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 +, 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.commailto:jonathan.leff...@gmail.com wrote: On Mon, Sep 12, 2011 at 10:29, Byrd, Brendan byr...@insightcom.commailto: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
Re: New NestedHash module needs home
On Wed, Sep 21, 2011 at 03:17:53PM +, 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::TreeDataMumble
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 +, 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.commailto:jonathan.leff...@gmail.com wrote:
On Mon, Sep 12, 2011 at 10:29, Byrd, Brendan
byr...@insightcom.commailto: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
RE: New NestedHash module needs home
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 +, 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.commailto:jonathan.leff...@gmail.com wrote:
On Mon, Sep 12, 2011 at 10:29, Byrd, Brendan
byr...@insightcom.commailto: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
Re: New NestedHash module needs home
On Tue, Sep 13, 2011 at 7:50 AM, Jonathan Leffler jonathan.leff...@gmail.com wrote: On Mon, Sep 12, 2011 at 10:29, Byrd, Brendan 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
Re: New NestedHash module needs home
Did you consider DBIx::NestedHash? Would that make any sense? On Mon, Sep 12, 2011 at 10:29, Byrd, Brendan byr...@insightcom.com wrote: I currently have a working and tested model for a “nested hash to table” conversion. [...] ** ** My dilemma is: Where exactly should this kind of module go in the CPAN namespace? There’s a number of potential choices that I see: ** ** *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... -- Jonathan Leffler jonathan.leff...@gmail.com #include disclaimer.h Guardian of DBD::Informix - v2011.0612 - http://dbi.perl.org Blessed are we who can laugh at ourselves, for we shall never cease to be amused.
