Hi Carl! I'm sorry I missed that. Try to change that line to $dbic->discard_changes unless($dbic->$rel);
All tests pass. I'm not sure why the PK is being lost in the process. I had to set the relationship to some value because otherwise DBIC would complain that the relationship could not be resolved because the column is not yet loaded. One way around this is to refetch the row, which is done by calling ->discard_changes. If this doesn't help, it would be great if you could provide a test case so we can nail this down. Cheers, moritz Am 02.03.2010 um 02:56 schrieb Carl Franks: > On 20 February 2010 17:10, Moritz Onken <[email protected]> wrote: >> Hi, >> >> this is a patch to allow a form to create a row in a belongs_to related >> table. This was not working till now. The Band.pm class had actually a wrong >> relationship set which made it look like it would work. I also added a test >> to confirm my findings. > > Hi Moritz, > > I've had a problem with an existing application, in which the $row > object created by $form->model->create() > is getting it's PK value stomped on, such that $row->id() returns undef. > > I've narrowed it down to this line in this patch: > $dbic->$rel(undef) unless($dbic->$rel); > > Before that's called, the PK has the expected auto-increment value, > after it's called, it's undef. > > I can't find any documentation on what passing the `undef` value is > meant to do, and don't know what part of the DBIx::Class code gets run > at that point. > Of course, commenting it out causes your new test to fail. > > Can you give me any pointers of what that DBIC code is doing? > > Cheers, > Carl > > _______________________________________________ > HTML-FormFu mailing list > [email protected] > http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu _______________________________________________ HTML-FormFu mailing list [email protected] http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu
