Skip Menu |
 

This queue is for tickets about the DBIx-Class-InflateColumn-Object-Enum CPAN distribution.

Report information
The Basics
Id: 95597
Status: resolved
Priority: 0/
Queue: DBIx-Class-InflateColumn-Object-Enum

People
Owner: jmmills [...] cpan.org
Requestors: josh [...] ziprecruiter.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

Attachments


Subject: Use of uninitialized value $_ in anonymous hash for is_nullable enum
Date: Mon, 12 May 2014 16:37:35 -0700
To: bug-DBIx-Class-InflateColumn-Object-Enum [...] rt.cpan.org
From: Josh Rosenbaum <josh [...] ziprecruiter.com>
So we started to notice these warnings being produced after updating to 0.05 from DBIx-Class-InflateColumn-Object-Enum-0.04: ------------------------------------------------------ Use of uninitialized value $_ in anonymous hash ({}) at /usr/local/share/perl/5.14.2/ Object/Enum.pm line 160 ------------------------------------------------------ I took a look at the diff: http://search.cpan.org/diff?from=DBIx-Class-InflateColumn-Object-Enum-0.04&to=DBIx-Class-InflateColumn-Object-Enum-0.05#lib/DBIx/Class/InflateColumn/Object/Enum.pm In particular this code was added: ------------------------ push(@{$values}, undef) if defined($info->{is_nullable}) && $info->{is_nullable}; ------------------------ As can be seen, if is_nullable is set, undef is added to the list of values that are passed via this line further down: Object::Enum->new({values=>$values}). Then Object::Enum::new() does this: $gen->_values({ map { $_ => 1 } @{$arg->{values}} }); This spits out a warning, because of using undef as a hash key. Since undef gets converted down to an empty string, this seems to be a bug to me. I decided to patch this, however, there seems to be a lot of weird uses of the empty string as undef in this module's tests. I've attached my patch, but if you run the tests, you will see it breaking in lots of areas, because of empty string as undef. As far as I can tell, DBIx never inflates undef columns, so I'm not sure if this is being done to try and avoid that? Since I can't read minds and don't know what the intentions are for this module I felt I should just report this with my patch and the code to trigger the original problem and see what the author thinks the proper course of action is. (Both are attached.) Thanks, -- Josh Rosenbaum P.S. As a side note, if the original push into $values needs to be kept, we should probably make a copy of the array first so we don't modify the original one. So this line: my $values = $info->{extra}->{list}; would become something like: my $values = [ @{ $info->{extra}->{list} } ];

Message body is not shown because sender requested not to inline it.

Message body is not shown because sender requested not to inline it.

Download (untitled) / with headers
text/plain 2.3k
I think the proper behavior here is to not have undef added to the list of values. Object::Enum::value does a croak if trying to set to an undef. I will address this after I've done the next release of Object::Enum. On Mon May 12 19:37:52 2014, josh@ziprecruiter.com wrote: Show quoted text
> So we started to notice these warnings being produced after updating > to > 0.05 from DBIx-Class-InflateColumn-Object-Enum-0.04: > ------------------------------------------------------ > Use of uninitialized value $_ in anonymous hash ({}) at > /usr/local/share/perl/5.14.2/ > Object/Enum.pm line 160 > ------------------------------------------------------ > > I took a look at the diff: > http://search.cpan.org/diff?from=DBIx-Class-InflateColumn-Object-Enum- > 0.04&to=DBIx-Class-InflateColumn-Object-Enum- > 0.05#lib/DBIx/Class/InflateColumn/Object/Enum.pm > > In particular this code was added: > ------------------------ > push(@{$values}, undef) > if defined($info->{is_nullable}) > && $info->{is_nullable}; > ------------------------ > > As can be seen, if is_nullable is set, undef is added to the list of > values > that are passed via this line further down: > Object::Enum->new({values=>$values}). > > Then Object::Enum::new() does this: > $gen->_values({ map { $_ => 1 } @{$arg->{values}} }); > > This spits out a warning, because of using undef as a hash key. Since > undef > gets converted down to an empty string, this seems to be a bug to me. > > I decided to patch this, however, there seems to be a lot of weird > uses of > the empty string as undef in this module's tests. I've attached my > patch, > but if you run the tests, you will see it breaking in lots of areas, > because of empty string as undef. As far as I can tell, DBIx never > inflates > undef columns, so I'm not sure if this is being done to try and avoid > that? > > Since I can't read minds and don't know what the intentions are for > this > module I felt I should just report this with my patch and the code to > trigger the original problem and see what the author thinks the proper > course of action is. (Both are attached.) > > Thanks, > > -- Josh Rosenbaum > > P.S. As a side note, if the original push into $values needs to be > kept, we > should probably make a copy of the array first so we don't modify the > original one. So this line: > my $values = $info->{extra}->{list}; > would become something like: > my $values = [ @{ $info->{extra}->{list} } ];
Download (untitled) / with headers
text/plain 2.7k
This is now closed, fixed in 0.06. Please reference the POD for changes. Essentially ::InflateColumn::Object::Enum now delegates to Object::Enum for "unsettable" behavior, and DBIC for validation. On Thu May 29 19:20:12 2014, JMMILLS wrote: Show quoted text
> I think the proper behavior here is to not have undef added to the > list of values. > Object::Enum::value does a croak if trying to set to an undef. > I will address this after I've done the next release of Object::Enum. > > On Mon May 12 19:37:52 2014, josh@ziprecruiter.com wrote:
> > So we started to notice these warnings being produced after updating > > to > > 0.05 from DBIx-Class-InflateColumn-Object-Enum-0.04: > > ------------------------------------------------------ > > Use of uninitialized value $_ in anonymous hash ({}) at > > /usr/local/share/perl/5.14.2/ > > Object/Enum.pm line 160 > > ------------------------------------------------------ > > > > I took a look at the diff: > > http://search.cpan.org/diff?from=DBIx-Class-InflateColumn-Object- > > Enum- > > 0.04&to=DBIx-Class-InflateColumn-Object-Enum- > > 0.05#lib/DBIx/Class/InflateColumn/Object/Enum.pm > > > > In particular this code was added: > > ------------------------ > > push(@{$values}, undef) > > if defined($info->{is_nullable}) > > && $info->{is_nullable}; > > ------------------------ > > > > As can be seen, if is_nullable is set, undef is added to the list of > > values > > that are passed via this line further down: > > Object::Enum->new({values=>$values}). > > > > Then Object::Enum::new() does this: > > $gen->_values({ map { $_ => 1 } @{$arg->{values}} }); > > > > This spits out a warning, because of using undef as a hash key. Since > > undef > > gets converted down to an empty string, this seems to be a bug to me. > > > > I decided to patch this, however, there seems to be a lot of weird > > uses of > > the empty string as undef in this module's tests. I've attached my > > patch, > > but if you run the tests, you will see it breaking in lots of areas, > > because of empty string as undef. As far as I can tell, DBIx never > > inflates > > undef columns, so I'm not sure if this is being done to try and avoid > > that? > > > > Since I can't read minds and don't know what the intentions are for > > this > > module I felt I should just report this with my patch and the code to > > trigger the original problem and see what the author thinks the > > proper > > course of action is. (Both are attached.) > > > > Thanks, > > > > -- Josh Rosenbaum > > > > P.S. As a side note, if the original push into $values needs to be > > kept, we > > should probably make a copy of the array first so we don't modify the > > original one. So this line: > > my $values = $info->{extra}->{list}; > > would become something like: > > my $values = [ @{ $info->{extra}->{list} } ];


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.