Just
to give feedback on this, I have completely reinstalled Perl using IndigoPerl
(installing all the modules for DBIx was a long winded business I can tell
you). And that didn't work so then I completely reinstalled Active State
Perl.
But
now it's even worse - the DBIx Loader itself is now not working
AND produces a whole load of these unreferenced scalar messages. I've
tried a variety of different tinkerings with different modules from active state
and Winnipeg without success. I haven't tried recompiling DBI with gcc
because I'm not even sure what that means. I looked up what gcc is but I
thought Perl was an interpreted language so I can't see how I can compile the
DBI module. No doubt there is an obvious answer to this and all you Perl
gurus are raising your eyes to the heavens but I'd rather not experience the
learning curve if I can avoid it - I have spent days on this now without getting
too far so I'm going to revert to Class::DBI and see if I can get going quicker
with that.
There
was one interesting point though in case this of any use for
developers. Although it popped up unreferenced scalar messages, the DBI
Loader loaded one table but failed as soon as it started my next table.
Here's the error:
Can't use an undefined value as an ARRAY reference at
C:/perl/site/lib/DBIx/Class/Schema/Loader/DBI.pm line
99.
So I
had a tinker with this and discovered that if I added a single print statement
here:
# Returns an
arrayref of column names
sub _table_columns {
my ($self, $table) = @_;
sub _table_columns {
my ($self, $table) = @_;
my $dbh = $self->schema->storage->dbh;
if($self->{db_schema}) {
$table = $self->{db_schema} . $self->{_namesep} . $table;
}
$table = $self->{db_schema} . $self->{_namesep} . $table;
}
my $statement =
"SELECT * FROM $table WHERE 1=0";
my $sth = $dbh->prepare($statement);
$sth->execute;
print "Num values found "[EMAIL PROTECTED]>{NAME_lc}}."<br>";
return [EMAIL PROTECTED]>{NAME_lc}};
}
my $sth = $dbh->prepare($statement);
$sth->execute;
print "Num values found "[EMAIL PROTECTED]>{NAME_lc}}."<br>";
return [EMAIL PROTECTED]>{NAME_lc}};
}
it
works and loads all the tables!! Bizarre. Still getting unreferenced
scalar messages, though. I think this shows that it is some kind of
threading error.
thanks,
James.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of James Masters
Sent: 25 August 2006 11:49
To: [email protected]
Subject: Re: [Dbix-class] Problem with DBIx::Class::Schema::Loader orThanks for your helpful further tips. The missing module was Module::Find. I think this was a red herring due to a mistake in where I had placed one of my hand-made modules. I've reworked this and now->load_classes does work so Module::Find is not needed apparently. i.e. you were right; it was my mistake in the way I set up the schema modules.On lower case column names, OK thanks. I understand.On this unreferenced scalar, issue. I have upgraded DBI from 1.5 to 1.52 but this unfortunately has not fixed it. I've upgraded almost all other modules to the latest win32 releases found at Winnipeg Uni too but without success. Googling, I can see this error message crops up a lot all over the place and everyone seems to relate it to problems with threading. In fact, many times it's attributed to a bug in PERL itself although I think these might be old posts. (Incidentally I'm running A/S PERL "v5.8.6 built for MSWin32-x86-multi-thread"). Perhaps one of the modules I'm running is not thread-safe for win32. There are also some vague remarks about having threads "enabled". So I'm wondering if I can disable threads somehow, maybe via an env. variable. I can't find out how, though. Does anyone know if this is possible?I have already had a quick look at SQL/Abstract/Limit but I'm afraid I am at the limit of my knowledge and I just wouldn't dare to try to tinker with it. The code in there is meaningless to me. It's V0.12 and the line says:return $self->_find_syntax_from_database($db) if $db;Just in case, I have reinstalled SQL-Abstract and SQL-Abstract-Limit using PPM from Winnipeg Univ. Also, I've checked & the versions of these that I have are the same as the latest that CPAN shows.-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Brandon Black
Sent: 24 August 2006 23:21
To: [email protected]
Subject: Re: [Dbix-class] Problem with DBIx::Class::Schema::Loader or
On 8/24/06, James Masters <[EMAIL PROTECTED]> wrote:Thanks for the advice. I have been re-reading the documentation and have made some progress by using the Loader Debugger.Firstly, let me reply to your 2 points. Of course, I did first try to use ->load_classes. This didn't work - the error said I was missing a module; I can't remember the name of it now but I couldn't find a win32 version of it so gave up
First, you should stop right there and work on that problem. What is this missing module, why is it missing, and can it be fixed? This doesn't sound sane/normal. I've haven't heard about people who cannot use load_classes. And no, "use MG::Schema::Foo" is *not* an adequate substitute.
Anyway, with the debugger, I have learnt that the Loader was working fine. I can see all the tables, columns and PKs being loaded. Also I got the resultsets to work - the problem was that I was specifying CountryCode (which is indeed the correct name of my column) but to get it to work I have to use lower case "countrycode". Someone has told me that this is because MySQL columns are not case-sensitive and all columns are stored in lower case. [ Still, I don't think this is ideal behaviour personally as I like my "cased" column names. Wouldn't a better behaviour be for the methods to accept any case? Not sure if possible as might mess up other database interfaces - just wondering. ]
The Loader currently does force all column names to lower case. Normal DBIx::Class lets you specify them however you like, and honors that specification. The decision to lowercase them all in Schema::Loader just makes the code *much* simpler than dealing with all of the cross-vendor case issues that exist for what Loader is doing. At least for the time being, if you want CamelCase column names in DBIx::Class, you have to do it for yourself.
However, I am left with a problem. The following error:Attempt to free unreferenced scalar: SV 0x1fa7a5c, Perl interpreter: 0x224234 at C:/Perl/site/lib/SQL/Abstract/Limit.pm line 325.occurs every time I attempt to use a resultset. Tinkering has established that it occurs with each of the following lines.my @livecountries = $schema->resultset('Country')->search(live => 'Y');
my $m = $schema->resultset('Country')->next->countryname;
my @allcountries = $schema->resultset('Country')->all;
my $country = $schema->resultset('Country')->find(1)->countryname;
my $r = $schema->resultset('Region')->find(1)->regionname;
my $p = $schema->resultset('Product')->find(1)->description;If I put all 6 lines, it occurs 6 times. It happens if this is the last thing in the script.This only happens when the schema is loaded via Loader - it did not appear when the schema was loaded via my manually created module. The Loader debugger does not give any clues. If anyone can point me in the right direction for further reading/investigation, I'd be very grateful.
The error itself is pointing you somewhere. What's on line 325 of S::A::L? (and what version do you have installed from where?).
-- Brandon
_______________________________________________ List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class Wiki: http://dbix-class.shadowcatsystems.co.uk/ IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/ Searchable Archive: http://www.mail-archive.com/[email protected]/
