[html-formfu] Deflation stopped working correctly after upgrade to HTML-FormFu-0.01005

[Carl Franks]

On 16/10/2007, Barry Hoggard <bhoggard at gmail.com> wrote:
> Hello, all.  My application started throwing errors after I ugpraded
> HTML-FormFu to 0.01005, and it seems to be due to objects being
> stringified to HASH(xxx) rather than to their ID now.
>
> Here is my setup for a relatively simple object
>
> --
> use base 'DBIx::Class';
> __PACKAGE__->load_components(qw/ HTML::FormFu InflateColumn::DateTime
> PK::Auto Core /);
> __PACKAGE__->table("event");
> __PACKAGE__->add_columns(qw/ event_id name description location url
> recommended toppick image /);
> __PACKAGE__->add_columns(
>                          start_date    => { data_type => 'date' },
>                          end_date      => { data_type => 'date' },
>                          opening_start => { data_type => 'datetime' },
>                          opening_end   => { data_type => 'datetime' },
>                          last_modified => { data_type => 'timestamp' },
>                         );
> __PACKAGE__->might_have( image => 'Artcal3::DB::Image', {
> 'foreign.image_id' => 'self.image' });
> __PACKAGE__->belongs_to( location => 'Artcal3::DB::Location' );
> __PACKAGE__->set_primary_key("event_id");
> __PACKAGE__->resultset_class('Artcal3::DB::Event::ResultSet');
> --
>
> The definition in YAML for the location field is
>
>  - type: Hidden
>    name: location
>
> If I use fill_formfu_values() on that object now, the form value for
> Location, which is a hidden field gets set to
> AC3Admin::Model::Artcal3DB::Location=HASH(0x4080be0) instead of the
> location's primary key.
>
> Any thoughts on what to fix here?

(Kinda replying to myself here, as Barry unsubscribed last week
without providing any more info that would have helped track this
down, maybe he'll be back...)

I don't see how this would have ever worked, unless the DBIC row class
was being overloaded to stringify to the primary-key, which doesn't
seem to be the case.

Anyway, it should work now - if the field name corresponds to a
relationship, and that related-table doesn't have an 'id' column, we
search for its primary column, and use that.

(any suggestions of how to handle multi-column PKs ? or should we just
ignore the related table if it's PK is multi-column ?)

Carl