title: dbix::class many-to-many with additional parameters as a JSON
body: <p>I have a many-to-many relationship in <code>DBIx::Class</code> similar to <a href="https://stackoverflow.com/questions/6112471/dbixclass-many-to-many-relationship-with-additional-attribute/6113179#6113179">DBIx:Class many-to-many relationship with additional attribute</a>.  Consider that same example on the <code>user_task</code> table with a <code>params</code> column which is type text.</p>
  <p>I've been using JSON strings in table columns and doing the inflate/deflate as in</p>
  <pre><code>__PACKAGE__-&gt;inflate_column(
      'params',
      {   inflate =&gt; sub {
              decode_json shift;
          },
          deflate =&gt; sub {
              encode_json shift;
          }
      }
  );
  </code></pre>
  <p>The result</p>
  <pre><code>use Data::Dump qw/dd/; 
  my $user_task = $schema-&gt;resultset(&quot;UserTask&quot;)-&gt;find({userid=&gt;1,taskid=&gt;1});
  
  dd {$user_task-&gt;get_columns}; 
  </code></pre>
  <p>results in</p>
  <pre><code>{userid=&gt;1,taskid=&gt;1,role=&gt;&quot;admin&quot;,params=&gt;&quot;{}&quot;}
  </code></pre>
  <p>however if</p>
  <pre><code>dd {$user_task-&gt;get_inflated_columns};
  </code></pre>
  <p>I don't get the expected result.  It appears that all of the columns are inflating. From the documentation <a href="https://metacpan.org/pod/DBIx::Class::Row#get_inflated_columns" rel="nofollow noreferrer">https://metacpan.org/pod/DBIx::Class::Row#get_inflated_columns</a>, it seems that it should only inflated those columns which have a <code>inflate_column</code> for.</p>
  <p>This also appears to be only on many-to-many bridge tables in that if I call <code>get_inflated_columns</code> on non-many-to-many results that the expected occurs.</p>
  <p><strong>Question</strong></p>
  <p>Is this a bug (or feature)?  If it is a feature, is there a reason this doesn't work?</p>
  <p>Alternatively, I can build up a result by selectively calling <code>get_inflated_column</code> on only the <code>params</code> column.  This seems like it should be unnecessary but perhaps a reasonable work around.</p>