[Dbix-class] bug with find_or_new and update_or_insert, for postgres DB

[Patrick Weemeeuw]

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 the where-clause values are copied to the row, in the
> > other case they are not. And I am certainly not confident enough in SQL
> > semantics to have much of an opinion what should happen with an
> > undef/NULL value in the where clause.
>
> (I may have chopped too much there, but this was getting long).
>
> There may be a DB where submitting NULL to a NOT NULL field which is
> auto-inc does the required thing, but it's not sane, IMO.
>
> Most prefer either "don't supply it" or want "DEFAULT" instead which is
> saner and iirc standard.
>
> If the system you are using does this on purpose, take it out and shoot
> it.. or fix it.
>
> Jess
>

Hi Jess,

Thank you for your continued feedback.

I agree about that insane behaviour; i.e. specifying id =>
undef that triggers the sequence for providing a value at
insertion time.

However, that id => undef attribute setting was returned by
find_or_new({id => undef}). In my opinion, find_or_new
should return a row in the DB satisfying the given
condition. If no such row is found, it should return a
_empty_, _new_ row, not one where one column is already
instantiated (with an invalid value in this case, given the
not null constraint).

So, my complaint is not about that update_or_insert doesn't
work in this situation, but about find_or_new filling in
attributes with values it found in the where condition.

And, in my previous posts, I claim that this is an existing
use case for submitting web forms, using the same code for
inserting a new record and updating an existing one.

-- patrick