How to override methods which use my() variables?

[Mur]

I just know I'm going to smack myself in the forehead when I get the answer to this, but I'm having a mental block today.

I'm making use of a CPAN package (DBIx::TextIndex as it happens, but it could be nearly any such package). Within the package the author has provided for extension to "your-favorite-RDBMS" by means of something like this:

my $db = 'DBIx/TextIndex/' . $args{db} . '.pm';
require "$db";

My problem arises in that the rest of the package makes heavy use of "my" variables. Those variables are invisible to the code I provide in my "database".pm file, and in fact any use of them results in a 'Global symbol "%FOO" requires explicit package name'.

Must I prefix FOO with DBIx::TextIndex::, or is there another way? Should the author of the package used some other means of declaring variables, or is the require at fault?

--
Jeff Boes Database Engineer Nexcerpt, Inc.	vox 269.226.9550 ext 24 fax [phone]  http://www.nexcerpt.com
...Nexcerpt...Connecting People With Expertise

[adrianh]

If the author is declaring the variables as lexically scoped within a file using "my" then they probably intend for them to be restricted to that file.

Can you give a more detailed explanation of what are trying to do with DBIx::TextIndex and why you think you need to get at a lexical?

You've probably got a valid problem but are asking the wrong question - if you see what I mean :-)

[Mur]

Sure. DBIx::TextIndex ships with MySQL support (only); I'm trying to adapt it to work with PostgreSQL. However, the way the author implemented the database-specific support was to accept a parameter, "db => $dbname", and construct a partial file path, essentially via

$db = "DBIx/TextIndex/${db}.pm"
require $db;

Thus, any db-specific code must reside in that file. In particular, it's intended that functions defined in that file return valid SQL statements as text for certain operations like CREATE TABLE, UPDATE, SELECT, etc.

The problem comes from the MySQL-centric code ... several of the internal operations involve putting a row in a table via "REPLACE INTO", which has no corresponding statement in most other RDBMS, including PostgreSQL. I really have to perform a DELETE and INSERT at that point, or a SELECT followed by an UPDATE (if successful) or an INSERT (if not). And I can't do the delete in the function that returns the SQL code, because the caller doesn't provide any info about parameters at that point; instead, it takes the SQL and executes it in a loop.

The code in TextIndex expects only a single SQL statement to be returned. Thus, I need to provide a function to override the TextIndex function, so that it gets both the DELETE statement and the INSERT statement, prepares both, and executes both in a loop.

The problem is that the function I'm overriding makes use of a lexical defined elsewhere in the package. At this point I think my only options are to rewrite the whole package or writing a new class that inherits from the old.

--
Jeff Boes Database Engineer Nexcerpt, Inc.	vox 269.226.9550 ext 24 fax [phone]  http://www.nexcerpt.com
...Nexcerpt...Connecting People With Expertise

[adrianh]

Ahhh... understand now. You're right, the DB specific module is a bit hard to extend to anything apart from MySQL. Not even a proper factory class which is what I assumed. Eww...

If you're feeling nice (and have the time) I'd patch the main module to cope with multiple SQL statements and send the patch to the module author along with your new and funky DBIx::TextIndex::pg extension.

If you can't spare the time, drop a line to the author anyway so they know there's a problem (it's the only way it they get fixed :-)

If you're into a evil hack type solution take a look at PadWalker, which can access lexical vars in calling subroutines.

Alternatively I think you could subvert the intent of the DBIx::TextIndex::whatever methods and actually run the SQL there. You're passed $self so you have access to the database handle. This would probably be excessively evil tho :-)