There is a small bug in find_or_new: when the find part
fails, it calls new_result with the hash containing the
values that were used for the search. It should use no
values at all instead.
Example buggy case: $o = $...->find_or_new( { id => $id } )
with id a not null primary key. When $id is undefined, there
is obviously no row in the DB, and a new result object is
returned. However, the object returned contains the column
id => NULL, which (1) is invalid for this kind of object,
and (2) prevents in some backends (e.g. Pg) that the
sequence is used to generate a unique id.
$ diff -U 5 ResultSet.pm.orig ResultSet.pm
--- ResultSet.pm.orig 2007-10-31 22:08:51.000000000 +0100
+++ ResultSet.pm 2008-01-12 09:25:52.000000000 +0100
@@ -1552,11 +1552,11 @@
sub find_or_new {
my $self = shift;
my $attrs = (@_ > 1 && ref $_[$#_] eq 'HASH' ? pop(@_) : {});
my $hash = ref $_[0] eq 'HASH' ? shift : [EMAIL PROTECTED];
my $exists = $self->find($hash, $attrs);
- return defined $exists ? $exists : $self->new_result($hash);
+ return defined $exists ? $exists : $self->new_result({});
}
=head2 create
=over 4
_______________________________________________
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/[EMAIL PROTECTED]
