> 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 >
2011/11/23 Brendan Byrd <sineswi...@gmail.com>: > Well, I'd actually be using schema as a MIB name. Which is horribly wrong. Tables names like systemGroup are always full qualified. There is no other oid named systemGroup as the one below mib_ii. > 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. This could be easily handled by an DBI::DBD::SqlEngine::Table derived. It's fully documented an illustrated by DBD::File how to create internal aliasing for table names. > As far as testing, that's why I'd like to add this in as a flag. I still do not understand what kind of flag you want to add and what behavior should be changed when activated. > 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? When you write a Pure-Perl DBD using SQL::Statement, you're well advised to derive from DBI::DBD::SqlEngine (unless you need to deal with files, then derive from DBD::File). And DBI::DBD::SqlEngine falls back to DBI::SQL::Nano in case no suitable SQL::Statement has been found. You're invited to join active discussion on irc://irc.perl.org/#dbi if you can't figure out all details on your own. Best regards, Jens A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
