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)



Subject: Allowing for schema.table format
Download (untitled) / with headers
text/plain 868b
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.
Download (untitled) / with headers
text/plain 1.6k
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
Download (untitled) / with headers
text/plain 111b
No new results in discussion on dbi-dev@ in November 2011 and no new try to argue leads to rejecting this wish.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.