Use deep merge for column info when adding columns

[robrwo]

The add_columns method uses a shallow merge of column
information. But the problem is that information in
"extra" is overwritten rather than merged.

This fixes the following issue:

__PACKAGE__->add_column(
  x => {
    data_type => 'enum',
    extra     => {
      list => [qw/ success fail /],
    }
  }
);

__PACKAGE__->add_column(
  '+x' => {
    extra => {
      something_else => ...
    }
  }
);

[robrwo]

If using Hash::Merge is not considered palatable, then an alternative might be to merge the extra columns separately using a _merge_column_info method that can handle the "extra" key.

[ribasushi]

The more important issue here is that it is not clear cut what does handle the "extra" key actually mean. Currently if one wants to rewrite the extra contents, they can do it with a +foo. After your patch - they will no longer be able to.

As your patch came without an extensive test case, it is difficult for me to figure out what your use case is. I suspect that you simply find the behavior you are proposing a better default, and could do what you want today instead as:

__PACKAGE__->add_column(
  '+foo' => { ... extra => {
    %{ __PACKAGE__->column_info("foo")->{extra} || {} }
    < extra stuff above or below this line depending whether you want override or default else >
  } }
);

I am in general very disinclined changing established behavioral defaults. Please explain in more detail why this case warrants an exemption.

P.S. I am leaving on a week-long trip: might not read/respond for a while

[robrwo]

@ribasushi Good point about users overwriting "extra" vs merging.

How about, it keeps the current behaviour, but if the column info has a "+extra" field, then it merges that instead of overwriting it?

FYI, the use case is for DBIC::Helper::Row::Enumeration, so that devs can override default handlers. I thought adding configuration in "extra" made sense.