Skip Menu |

This queue is for tickets about the SQL-Statement CPAN distribution.

Report information
The Basics
Id: 72588
Status: rejected
Priority: 0/
Queue: SQL-Statement
People
Owner: Nobody in particular
Requestors: BBYRD [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Mon Nov 21 13:26:13 2011 BBYRD [...] cpan.org - Ticket created
Subject: Allowing for schema.table format
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. 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.
  Tue Nov 22 02:03:07 2011 HMBRAND [...] cpan.org - Correspondence added
On Mon Nov 21 13:26:13 2011, BBYRD wrote: Show quoted text
> 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.
Maybe that is - amongst several other possibilities - because the code is already used by many other DBD's, like DBD::File (which is also the base for DBD::CSV) and DBD::DBM. For the complete list see http:// deps.cpantesters.org/depended-on-by.pl?module=SQL%3A%3AStatement IMHO unquoted table names with special characters like you here use '-' would never be fitting in any standard Show quoted text
> 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 Show quoted text
> schema.table format? I have removed the code to test with, and it > appears to work just fine (so far).
I personally would cheer for all possible new or improved support, but if you are avout to suggest changes to SQL::Statement, please test all the modules that currently depend on it with the changed set. Integrations goes rather deep nowadays. Show quoted text
> 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.
A better place to discuss this might be the DBI development mailing list, where you get pruning eyes from many DBD authors: dbi-dev@perl.org
  Tue Nov 22 02:03:08 2011 The RT System itself - Status changed from 'new' to 'open'
  Tue Oct 02 10:52:03 2012 REHSACK [...] cpan.org - Correspondence added
No new results in discussion on dbi-dev@ in November 2011 and no new try to argue leads to rejecting this wish.
  Tue Oct 02 10:52:04 2012 REHSACK [...] cpan.org - Status changed from 'open' to 'rejected'