DBIx::Class::Schema::Loader prob

[jfrm]

Hello learned Bretheren,

I have managed to get DBIx::Class working using mysql. Here's my code:

# set up a schema class using 2 modules that I've written manually (th
+ere are more tables; this is just to make sure it works).
use MG::Schema::Tables;   # *
use MG::Schema::Country;  # *
my $schema = MG::Schema->connect('DBI:mysql:mg', 'jfrm', '???'); #* 

# Or better, fill the class with table info automatically (using a fil
+e called MG/Main.pm with content:
#package MG::Main;
#use base qw/DBIx::Class::Schema::Loader/;
#__PACKAGE__->loader_options(
#    relationships           => 1);

#use MG::Main;    #&
#my $schema = MG::Main->connect('DBI:mysql:mg', 'jfrm', '????'); #&

# Query for all countries and put them in an array,
my @all_countries = $schema->resultset('Country')->all;

# Create a result set to search for countries.
foreach my $country (@all_countries) {
    print "! ".$country->CountryCode." = ".$country->CountryName."<Br>
+";
    }

So then I want to change to not have to write all the schemas out manually into modules by using the Schema::Loader module. So I comment out the 3 lines labelled #* and uncomment the 2 lines with #&. Here's the error:

[Wed Aug 23 18:22:49 2006] mgdb.pl: Attempt to free unreferenced scala
+r: SV 0x1fa7a5c, Perl interpreter: 0x224234 at C:/Perl/site/lib/SQL/A
+bstract/Limit.pm line 325.
[Wed Aug 23 18:22:49 2006] mgdb.pl:  at C:/Perl/site/lib/SQL/Abstract/
+Limit.pm line 325
Software error:
Can't locate object method "CountryCode" via package "MG::Main::Countr
+y" at C:/Information/mgroot/cgi-bin/mgdb.pl line 53.
 at C:/Information/mgroot/cgi-bin/mgdb.pl line 53

So my humble question for meditation is: Is this because I'm doing something wrong due to my very poor understanding of object methods? Or is it a bug in this Abstract::Limit module (in which case I'll do my best to put in a bug report if i can work out how)?

thanks for any advice.

[jesuashok]

Hi jfrm

did you check whether the connection is success or not.I found that your code, does not check for the status of connection

my $schema = MG::Schema->connect('DBI:mysql:mg', 'jfrm', '???');

If the object does not have the proper reference in it, then If you use the undefined scalar ( which is not a reference ) then you get the following error :-

[Wed Aug 23 18:22:49 2006] mgdb.pl: Attempt to free unreferenced scala
+r: SV 0x1fa7a5c, Perl interpreter: 0x224234 at C:/Perl/si

Becuase perl internally calls the SvREFCNT_dec() or SvREFCNT_inc() for all the references to free memory which corresponds to the references ( In your case it is a scalar ). In your case if the connection is not success then it should try to call the any ot the function, which in turn throws the error which you got.

[jfrm]

That was very helpful thanks. The connection was a success and with debug I can see all the tables and columns being set up. In fact there seem to be 2 problems, not 1. The first problem is the error message

Attempt to free unreferenced scalar: SV 0x1fa7a5c, Perl interpreter: 0
+x224234 at C:/Perl/site/lib/SQL/Abstract/Limit.pm line 325.

Some more tinkering has established that this is happening when the following line is executed:

@all_countries = $schema->resultset('Country')->all;

If I remove this line, it disappears. And yet it only happens when the schema is loaded via Loader - it does not appear when the schema is loaded via my manually created modules. The Loader debugger does not give any clues.

Further testing has established that the same message appears for the search, next and find methods in DBIx::Class::ResultSet. Also I've tried 3 tables and it happens with all. So it seems that the problem happens with multiple resultset methods against multiple tables but only when tables are loaded using the Loader module.

I'm not sure if it is related to the second problem which I will post as a separate response immediately following this post.

[jfrm]

I think I've finally got rid of my unreferenced scalar messages thanks to some pointers from Matt Trout and others. I've tried all sorts of ways around the problem but in the end, here is a summary of my final solution for the record. Experts might wish to correct technicalities, where I've been particularly amateur...

Bottom line seems to be that the DBI that comes with Active State Perl has problems (probably to do with threading) which cause errors like this:

Attempt to free unreferenced scalar: SV 0x1fa7a5c, Perl interpreter: 0
+x224234 at C:/Perl/site/lib/SQL/Abstract/Limit.pm line 325.

in a number of situations and certainly when using DBIx modules on Windows.

DBI is one of those modules that isn't just interpreted - part of it is compiled C++. A way to fix the problem is to overwrite DBI with a version that has been compiled using a different C++ compiler - recommended is gcc. gcc is the defacto standard open source C++ compiler. And, incidentally, MingW seems to be the most popular pre-compiled version of gcc and other related stuff for Windows. However, if one looks at the documentation that comes with gcc and one is not a C++ programmer, one becomes mightily scared. It appears that all sorts of stuff needs to be configured and downloaded and compiled so downloading and installing a pre-packaged C++ compiler seems a hugely attractive option by comparison. But, even with the free Microsoft C++ compiler or the free Intel C++ compiler or the free MingW C++ compiler, installation is not straightforward and for a non-C++ programmer, extremely off-putting. CamelPack Perl is an installer bundle of Active State Perl together with MingW C++ compiler and MS Nmake into a simple install package.

So first install Camel Pack Perl including the C++ stuff.

DBI comes with CamelPack Perl of course. So, if you try to install it using CPAN it will likely say "DBI is up to date." which leaves you up the creek without a paddle. So, being not easily put off, decide to do this by hand. As per the standard module installation instructions you (within CPAN) do the following:

make DBI
test DBI

at which point one of the tests fails - as is often the case with Windows (one wonders if one should even bother with these tests under Windows so often do they fail). Based on this pessimistic outlook and despite the fact that you aren't really supposed to install unless all tests pass, ignore this and also override the "DBI is up to date" message by typing

force install DBI

This seems to work and, for me, at least the unreferenced scalar messages and the inconsistent behaviour instantly disappeared.

I hope this non-expert perspective helps someone in the future.

[jfrm]

What the debugger did reveal is that the Loader seems to be changing the case of my column names. So while the following worked previously:

print "! ".$country->CountryCode." = ".$country->CountryName;

once the columns have been loaded with the Loader it fails but this works instead:

print "! ".$country->countrycode." = ".$country->countryname;

I thought this behaviour might be an option but I've looked all through DBIx::Class::Schema::Loader::Base documentation and can't see anything pertaining. Is this a bug or by design?

[insaniac]

I think this is because column names are not case sensitive in MySQL ;-) google reveals a lot ;-)

[jfrm]

Dear jesuashok,

That's a good idea. At first it was giving access denied errors but when I fixed that and the errors disappeared, I assumed that it was working. Also because the connection with #* definitely works, I assumed that the connection line with #& also would. Probably this was naive.

The only thing is that I'm not sure how to test for the connection. I've read through the documentation again for the 3 related modules but cannot see anything that's obvious enough for my non-object way of thinking. These methods seem rather alien to me. Can you enlighten me or point me to the document that I should be reading?

thanks.