I've run into this issue once before and thought I'd seen the last of it and it has resurfaced.
The solution last time was to get the latest and greatest DBD drivers loaded on the machine where the bad behavior was observed. This time I'm seeing the behavior for no apparent reason. All of the modules that I know about that are in play here are at their latest and greatest versions.
Here is the program in it's entirety:
When this is run I get the enigmatic error:#!/usr/bin/perl -w use Class::DBI::Loader; my $loader = Class::DBI::Loader -> new( dsn => "dbi:Pg:dbname=peter_bcdc", user => "pberghol", password => '$3cr3t$9u!rr31', # not real! options => { RaiseError => 1, AutoCommit => 1 }, namespace => 'Db', relationships => 1 ); while ( my $line=<DATA> ){ chomp $line; my ($given_name,$surname,$email) = split(",",$line); my $person = Db::Person -> find_or_create( {given_name => $given_name +, surname => $surname, email_addr=> $email } ); } exit(0); __END__ <data follows here, but is besides the point...>
Use of uninitialized value in split at /usr/lib/perl5/site_perl/5.8.5/ +Class/DBI/Pg.pm line 26. "location" has no primary key at /usr/lib/perl5/site_perl/5.8.5/Class/ +DBI/Loader/Generic.pm line 164
Liar! It does too have a primary key!
create table location ( location_id serial not null primary key, location_name text not null );
So... any thoughts on how to either fix this or work around it? I'd hate to think I have to go back to my old ways of writing my own objects to handle tables...
Manually executing the SQL and taking some scientific wild assed guesses (SWAG) as to what should be put in place of the placeholder I got the following result.SELECT indkey FROM ${catalog}pg_index WHERE indisprimary=true AND indrelid=( SELECT oid FROM ${catalog}pg_class WHERE relname = ?)
Not sure that was the result the module was expecting and yet that doesn't in my mind explain the error code. Still curious... still don't have an answer...peter_bcdc=# SELECT indkey FROM pg_catalog.pg_index WHERE indisprimary=true AND indrelid=( SELECT oid FROM pg_catalog.pg_class WHERE relname = 'location'); indkey -------- 1 (1 row)
Hacking away at the module Class::DBI::Pg and adding more and more diagnostic print statements in I made an interesting discovery. The last (so far) debugging statement I added prints out one of the parameters being passed to the module, which is the name of the table. Obverve this sniglet:
event_class event_date event_type instructor instructor_type_map "location"
Notice that the tables prior to "location" are not quoted but location is. Something tells me this is significant... further checking is in order here...
Once I renamed this table from "location" to "place" everything was hunky dory. That still leaves open the issue that in the future where anymonk might not have control over table names in a database schema this might raise its ugly head again. Things I am planning on following up on:
Prior to this I found out that Class::DBI::Loader and friends get upset when you have a table named "class" as does the Hibernate Java POJO persistance layer. Seems you can't have a Java POJO named "Class"... gee... I wonder why? :=)
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |