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
Tim [who is happy to know almost nothing about snmp]
