2011/11/23 Tim Bunce <tim.bu...@pobox.com>: > On Wed, Nov 23, 2011 at 09:34:06AM +0100, Jens Rehsack 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. > > Perhaps quote the schema indentifier to enable embedded periods: > > SELECT * FROM "enterprises.smart-snmpd.20.1".smDiskIoTable
This is double adressed and would result in: SELECT * FROM ".1.3.6.1.2.1.4.1.1.3.6.1.2.1.4.1.36539.20.1.1.3.6.1.2.1.4.1.1.3.6.1.2.1.4.1.36539.20.1.3" which is horribly wrong, because it must be SELECT * FROM ".1.3.6.1.2.1.4.1.36539.20.1.3" Well, you can argue that you strip common prefixes, but it's ambiguous and can mislead to invalid oids. (whereby 1.3.6.1.2.1.4.1 = enterprises, .1.3.6.1.2.1.4.1.36539 = smart-snmpd and .1.3.6.1.2.1.4.1.36539.20.1.3 = smDiskIoTable). And shall SELECT * FROM .1.3.6.1.2.1.4.1.36539.20.1.3" be the same as SELECT * FROM smDiskIoTable (read: should smDiskIoTable resolved into it's oid before querying)? Shall SQL::Statement identify both names as the same table or shall both have incidentally the same content? > Tim [who is happy to know almost nothing about snmp] Lucky guy :D SNMP isn't so difficult as it sounds, but it's different than SQL and 1:1 mapping wouldn't work from my perspective. Probably some SNMP plugins for DBD::Sys might a better idea. /Jens
