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 unde
On Tuesday 08 January 2008 00:46:05 Jess Robinson wrote:
> On Mon, 7 Jan 2008, Patrick Weemeeuw wrote:
> > So, I don't know whether the find_or_new method should create an
> > embryonic row that satisfies the conditions of the where clause, or not.
> > In the first case t
On Monday 07 January 2008 10:43:49 Jess Robinson wrote:
> On Sun, 6 Jan 2008, Patrick Weemeeuw wrote:
> > | create table article (
> > | artId integerNOT NULL DEFAULT
> > | nextval('article_artid_seq'), day char(8)NOT NULL,
Analyzing the problem a bit more, I found out that, in generic terms,
find_or_new({ pk_col => undef })
creates an internal row, and that the successive insert fails to substitute
the pk_col with a value from the sequence, probably because the value has
been explicitly set.
I'm not sure whether
See below.
BTW: thanks for this great package!
-- patrick
DB schema (postgres):
| CREATE SEQUENCE article_artid_seq;
|
| create table article (
| artId integerNOT NULL DEFAULT
nextval('article_artid_seq'),
| day char(8)NOT NULL,
| seqnr inte
