[Dbix-class] A more accurate redux of zby's comments

Carl Franks fireartist at gmail.com
Thu Jan 24 12:12:34 GMT 2008


On 24/01/2008, Matt S Trout <dbix-class at trout.me.uk> wrote:
> On Thu, Jan 24, 2008 at 08:53:08AM +0100, Zbigniew Lukasiak wrote:
> > This started with me trying to add some new features to create - they
> > were rejected because I was using update_or_create and it does not
> > always work, so I went and tried to fix update_or_create and I found
> > out that this bug is a result of two things:
> >
> > 1. that you need to delete the primary key when you have them
> > undefined and try to insert the row in PostgreSQL
> > 2. that when you delete the pk instead of leaving it undef then find
> > will not work as advertised
> >
> > My plead to a workaround for 1) - by simply deleting the PK in the Pg
> > storage driver was rejected so those that use PostgreSQL are forced to
> > live with the consequences of using find with the PK deleted.
>
> That's because Postgres' behaviour in this situation is correct.

For some context, and a resolution...

zby came across this problem while working with HTML::FormFu::Model::DBIC.
HTML::FormFu provides a 'repeatable' block of fields, which can
correspond to a many-to-many relationship, to allow you to edit
multiple rows at a time (example: edit a user's details, and all their
associated addresses at the same time).

If you enable the option to render an extra, empty repetition of the
block of fields to insert a new record, the code was using the empty
hidden field corresponding to the PK.
I've argued that it's the code on our end that's broken, and zby's
going to patch HTML::FormFu::Model::DBIC to be a little more
intelligent about it!

Cheers,
Carl



More information about the DBIx-Class mailing list