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

> On Wed, Nov 23, 2011 at 3:34 AM, Jens Rehsack <[email protected]>
> 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.
>>
>> 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 <[email protected]>
>> > Computer tech, Perl wizard, and all-around Internet guru
>> >
>
>
>
> --
> Brendan Byrd/SineSwiper <[email protected]>
> Computer tech, Perl wizard, and all-around Internet guru
>

2011/11/23 Brendan Byrd <[email protected]>:
> 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?