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

2011/11/23 Tim Bunce <[email protected]>:
> On Wed, Nov 23, 2011 at 09:34:06AM +0100, Jens Rehsack 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.
>
> 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