Re: Allowing for schema.table format in SQL::Statement

Well, I'd actually be using schema as a MIB name.  For example,
IF_MIB.ifTable or SNMPv2_MIB.systemGroup.  Dashes are converted to
underscores, since MIBs don't use underscores and SQL doesn't like dashes.

As far as testing, that's why I'd like to add this in as a flag.  Testing
is still required, but if the default is what it's always has been, it's
not going to be a drastic change for those modules.  I'm not sure about
Nano; should this change be in Nano?

On Wed, Nov 23, 2011 at 3:34 AM, Jens Rehsack <[email protected]>wrote:

> 2011/11/22 Brendan Byrd <[email protected]>:
> > (Adding dbi-dev to conversation for
> > https://rt.cpan.org/Ticket/Display.html?id=72588)
> >
> > Still debugging DBD::SNMP right now, and I'm currently fighting with
> > SQL::Statement to allow for schema.table formats. The idea would that it
> > would be possible to reference the MIB name within the table, like
> > IF_MIB.ifTable for IF-MIB::ifTable. However, I'm finding all kinds of
> code
> > that strips the schema from the table name.
>
> As far as I know, snmp tables doesn't have a scheme - they might (or might
> not)
> have a unique dot separated identifier path.
>
> Let's take dskTable as example. It's full qualified oid is ".
> 1.3.6.1.4.1.2021.9"
> or "enterprises.ucd.9" yada-yada-yada.
>
> How do you expect the schema.table support can help you and how it is
> required to be changed from current implementation (see DBD::File how
> currently it's used).
>
> Another example is smProcessStatus - or "enterprises.smart-snmpd.10.7"
> which has it's table at smProcessTable.1 or "1.3.6.1.4.1.36539.10.7.7.1".
> Or smDiskIoStatus (enterprises.smart-snmpd.20.1), which contains two
> tables: smDiskIoTable and smDiskIoIntervalTable.
>
> For details about this mib, you've currently have to download the
> tarballs from http://www.netbsd.org/~sno/smart-snmpd/.
>
> Nevertheless, I do not understand what kind of different schema
> handling would really help you on this.
>
> > So far, I've found code in parse, TABLE_NAME, IDENTIFIER, and
> open_tables.
> > So it seems that SQL::Statement -really- wants to remove the schema. What
> > kind of pitfalls would I encounter if I allowed for a schema.table
> format?
> > I have removed the code to test with, and it appears to work just fine
> (so
> > far).  For IDENTIFIER, I added this:
> >
> > return $self->IDENTIFIER($1) && $self->IDENTIFIER($2) if ( $id =~
> > m/^(.+)\.([^\.]+)$/ ); # check both schema/table
> >
> > I'd like to turn this into a patch, since I have a need to have these
> > available.  Given that this is a change to the general functionality of
> > SQL::Statement, I'm open to adding this in as a flag of some sort.
>
> Did you try all tests of SQL::Statement, DBD::File, DBD::DBM and DBD::CSV
> to prove against unexpected side effects? How do you add the compatible
> change to DBI::SQL::Nano?
>
>
>
> > --
> > Brendan Byrd/SineSwiper <[email protected]>
> > Computer tech, Perl wizard, and all-around Internet guru
> >
>



-- 
Brendan Byrd/SineSwiper <[email protected]>
Computer tech, Perl wizard, and all-around Internet guru