On Wed, Nov 23, 2011 at 9:15 AM, Jens Rehsack <rehs...@googlemail.com>wrote:
> > 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. > You do run into odd cases like RFC1213-MIB::sysDescr versus SNMPv2-MIB::sysDescr. Yes, I know RFC1213 is obsolete, but you still have old devices using stuff like atTable. The MIB name is optional, but putting it in would ensure it would actually hit the v2 version of sysDescr. And who knows what kind of bass-ackwards behavior is buried in some of those vendor MIBs. Still, I'll have to think about whether the support for those edge cases is worth it or not... > > 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. > Are we talking about the schema separator (dot), or the dash/underscores? I've tackled the latter, and I'm trying to use S::S to play nice with the former. > > 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. > The filtering of schemas within S::S. Basically, any time you specify something like schema.table, S::S strips the schema, and the driver has no idea (based on the Statement/Parser structure/methods) that the table ever had a schema. This would be a flag called 'dont_strip_schema' or something like that. 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. > Well, I'm using SQL::Parser during the ::db::prepare process, and I'm not sure if Nano has all of the parsing I need. I was going to make S::S a requirement of the module, anyway. > You're invited to join active discussion on irc://irc.perl.org/#dbi > if you can't figure out all details on your own. > Will do. Might have some other questions, anyway. 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? > Sorry, just realized that GMail is using this vertical line for quoting, which I can use. I generally don't like top-posting, either. 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? OIDs will only be used at the last step within the backend. I'm going to enforce proper table names only. (After all, if we don't have the MIB, we're shouldn't be poking around data points we don't understand or can even get data types from.) > 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. I disagree. I've worked with SNMP tables in this fashion before, for the purposes of translating a big batch of tables into CSV (which then gets uploaded to Oracle). It works, even if there isn't a table for every single object. I've found that the *accessible* objects boil down to four types: 1. Tables (NoAccess), which go to a Entry (NoAccess), which have indexes and columns, etc. IE: your typical table layout. 2. Table->Entry->Columns with a RowStatus field that allows for advanced updates/deletes/etc. 3. "Global" tables, where the index is always 0, such as systemGroup. 4. Notification/trap groups. All of these could be accessed via SQL with a translatable interface. Heck, I'm about 90% finished with the read-only version of this module, and I'm working out the bugs in getting Catalyst::Helper::Model::DBIC::Schema to produce a set of Result modules for it, complete with the foreign keys and all (since I have that support in foreign_key_info). -- Brendan Byrd/SineSwiper <sineswi...@gmail.com> Computer tech, Perl wizard, and all-around Internet guru
