Use of uninitialized value warning in DBIx/Class/ResultSet.pm line 2768 (and others)

[Daniel Austin]

[Woops. Sent this to the old list address. Take 2...]

Hi

I recently switched my DBIx::Class modules to using Result Sets. So I
have a MyCompany/Schema/Result directory with a bunch of modules that
inherit from DBIx::Class::ResultSet.

Apart from a few minor issues the regression tests all pass now except
I've started getting thousands of warnings like this:

    Use of uninitialized value in concatenation (.) or string at
./lib/perl5/DBIx/Class/ResultSet.pm line 2768.

The variable in question is $alias which comes out of $self->{attrs}->{alias}.

Changing line 2761 to this:

      my $alias  = $attrs->{alias} || '';

suppresses the warning but not sure if it's correct (all the
DBIx::Class tests seem to still pass).

The first few lines of my classes all look like this:

   package MyCompany::Schema::Result::Centre;
   use strict;
   use warnings;
   use base 'DBIx::Class::ResultSet';
   __PACKAGE__->load_components("Core");
   __PACKAGE__->table("centre");
   __PACKAGE__->add_columns( ... );

(I was trying to follow the example in the Catalyst tutorial. I needed
to do it this way in order  to use some custom SQL)

Am I doing something wrong in setting up these classes? Or should I
work on a patch that takes care of the case where attrs->alias is not
defined?

Thanks

Dan

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...

[Peter Rabbitson-2]

Daniel Austin wrote:

> [Woops. Sent this to the old list address. Take 2...]
>
> Hi
>
> I recently switched my DBIx::Class modules to using Result Sets. So I
> have a MyCompany/Schema/Result directory with a bunch of modules that
> inherit from DBIx::Class::ResultSet.
>
> Apart from a few minor issues the regression tests all pass now except
> I've started getting thousands of warnings like this:
>
>     Use of uninitialized value in concatenation (.) or string at
> ./lib/perl5/DBIx/Class/ResultSet.pm line 2768.
>
> The variable in question is $alias which comes out of
> $self->{attrs}->{alias}.
>
> Changing line 2761 to this:
>
>       my $alias  = $attrs->{alias} || '';
>
> suppresses the warning but not sure if it's correct (all the
> DBIx::Class tests seem to still pass).

They all pass because none of them have an empty alias. You are
certainly doing something very wrong, most probably when you do
the custom sql magic. Show relevant pieces of code, and also
tell us what version of DBIC are you running. Especially important
is the call which triggers the warning - what does it look like?

> The first few lines of my classes all look like this:
>
>    package MyCompany::Schema::Result::Centre;
>    use strict;
>    use warnings;
>    use base 'DBIx::Class::ResultSet';
>    __PACKAGE__->load_components("Core");
>    __PACKAGE__->table("centre");
>    __PACKAGE__->add_columns( ... );
>
> (I was trying to follow the example in the Catalyst tutorial. I needed
> to do it this way in order  to use some custom SQL)
>
> Am I doing something wrong in setting up these classes? Or should I
> work on a patch that takes care of the case where attrs->alias is not
> defined?
>
> Thanks
>
> Dan
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
> Searchable Archive: http://www.grokbase.com/group/dbix-class@...

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...

[Daniel Austin]

> [...]
> They all pass because none of them have an empty alias. You are
> certainly doing something very wrong,

I thought that must be the case. Wouldn't be the first time. :-)

> most probably when you do
> the custom sql magic.

I've backed that out but I still get the errors.

Here's my setup: I'm using DBIx::Class 0.08109 and Catalyst 5.80007.
Perl 5.8.8 running on OSX 10.5. Using PostgreSQL 8.3.4 with
DBIx::Class.

I have the following files:

lib/MyCompany/Schema.pm:
    package MyCompany::Schema;
    use strict;
    use warnings;
    use base 'DBIx::Class::Schema';
    __PACKAGE__->load_namespaces;

lib/MyCompany/Schema/Result/Customer.pm:
    package MyCompany::Schema::Result::Customer;
    use strict;
    use warnings;
    use Carp;

    use base 'DBIx::Class::ResultSet';
    use Data::FormValidator::Constraints qw(:closures);

    __PACKAGE__->load_components(qw/Validation Core/);
    __PACKAGE__->table("customer");
    __PACKAGE__->add_columns( ... );

There's quite a few classes like the above, all following the same
pattern. I did this since the documentation indicated it was the
preferred development practice these days, but also because one of
these classes has some custom SQL. But I've removed that from the code
at the moment and it hasn't fixed the problem.

Now, this is the code that triggers the warning (or at least it's one
of the lines):

    if ( $title !~ m/$custer->name/i) {

FYI, "$centre" is a DBIx::Class as defined by the code example above.
Now that I've tracked it down that regex doesn't look right to me. If
I comment that out I get much fewer warnings. So I've changed it to
this:

    my $centre_name = $centre->name;
    if ( $title !~ m/$centre_name/i ) {

I understand (I think) why the regex is wrong but I don't understand
why it failed the way it did and generated the warnings that I got.
Need to kick up my Perl skills a notch. Meanwhile, can anyone explain?

Running the full regression suite there are a few more places left
where I get these warnings. So far they all concern regular
expressions but not always regex's that involve a DBIx::Class object.
I'll keep digging.

Thanks for offering to help.

Dan

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...

[Peter Rabbitson-2]

Daniel Austin wrote:

>> [...]
>> They all pass because none of them have an empty alias. You are
>> certainly doing something very wrong,
>
> I thought that must be the case. Wouldn't be the first time. :-)
>
>> most probably when you do
>> the custom sql magic.
>
> I've backed that out but I still get the errors.
>
> Here's my setup: I'm using DBIx::Class 0.08109 and Catalyst 5.80007.
> Perl 5.8.8 running on OSX 10.5. Using PostgreSQL 8.3.4 with
> DBIx::Class.
>
> I have the following files:
>
> lib/MyCompany/Schema.pm:
>     package MyCompany::Schema;
>     use strict;
>     use warnings;
>     use base 'DBIx::Class::Schema';
>     __PACKAGE__->load_namespaces;
>
> lib/MyCompany/Schema/Result/Customer.pm:
>     package MyCompany::Schema::Result::Customer;
>     use strict;
>     use warnings;
>     use Carp;
>
>     use base 'DBIx::Class::ResultSet';
>     use Data::FormValidator::Constraints qw(:closures);
>
>     __PACKAGE__->load_components(qw/Validation Core/);
>     __PACKAGE__->table("customer");
>     __PACKAGE__->add_columns( ... );
>
> There's quite a few classes like the above, all following the same
> pattern. I did this since the documentation indicated it was the
> preferred development practice these days...

Stopping you right here - what lives in /Result/* are result classes,
(also known as row classes) not resultset classes. So every Result::*
should use base 'DBIx::Class' not ResultSet. Incidentally stuff in
/ResultSet/* is considered a resultset and every ResultSet::* is
expected to inherit from DBIx::Class::ResultSet.

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...

[Daniel Austin]

2009/8/27 Peter Rabbitson <[hidden email]>:
> Stopping you right here - what lives in /Result/* are result classes,
> (also known as row classes) not resultset classes. So every Result::*
> should use base 'DBIx::Class' not ResultSet. Incidentally stuff in
> /ResultSet/* is considered a resultset and every ResultSet::* is
> expected to inherit from DBIx::Class::ResultSet.

OK, this makes sense to me. I've made the mistake of making changes I
didn't fully understand. Rookie mistake really. Feel stoopid.

I'm tying myself in knots over the Catalyst tutorial recommending
load_namespaces here (instead of load_classes):
http://search.cpan.org/~hkclark/Catalyst-Manual-5.8000/lib/Catalyst/Manual/Tutorial/03_MoreCatalystBasics.pod

and the DBIx::Class cookbook's way of doing custom SQL
http://search.cpan.org/~ribasushi/DBIx-Class-0.08109/lib/DBIx/Class/Manual/Cookbook.pod

Actually, at the time I was using this version:
http://cpansearch.perl.org/src/RIBASUSHI/DBIx-Class-0.08107/lib/DBIx/Class/Manual/Cookbook.pod

Anyway, I'll fix this code back up and let you know if that fixes
these alias issues.

Thanks.

Dan

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...

[Daniel Austin]

OK, so my Results are Results and not ResultSets now and yes, that's
fixed those warnings. All the tests passed.

I'll take a look at the revised way of doing custom SQL.

Thanks for the help!

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@...