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 <rehs...@googlemail.com>wrote: > 2011/11/22 Brendan Byrd <sineswi...@gmail.com>: > > (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 <sineswi...@gmail.com> > > Computer tech, Perl wizard, and all-around Internet guru > > > -- Brendan Byrd/SineSwiper <sineswi...@gmail.com> Computer tech, Perl wizard, and all-around Internet guru
