DBIx::Class::ResultClass::HashRefInflatorが無視されるケース

$rs->result_class(‘DBIx::Class::ResultClass::HashRefInflator’);
がときどき無視されてしまうのはこれかー.
http://lists.scsys.co.uk/pipermail/dbix-class/2008-February/005733.html

the custom result_class is written *only* into the $rs->{result_class} slot (by the result_class() accessor/mutator generated by Class::Accessor::Grouped), whereas when ResultSet->new() is (secretly) invoked to build the resulting resultset (yes, new() is called even on a simple find() with some \%attrs), the custom result_class is searched
*only* in the $rs->{attrs}{result_class} slot (please see ResultSet.pm line 101), which however is never assigned by the result_class() mutator. Consider also that ResultSet->new() is invoked this way ( from a ResultSet instance – for example by search_rs() ):
my $rs = (ref $self)->new($self->result_source, $new_attrs); so once in new() we’ve lost $self and the opportunity to read its result_class slot, which is why it should have somehow been copied into $new_attrs->{result_class} before calling new().

なんだってー!
まぁ,いかにもCatalyst的に起こりそうな不具合なので,もっと早く調べておけば良かったな.
DBIx::Class::ResultClass::HashRefInflatorはもともとラッパ関数経由で使っているので,そこんとこを
 $rs->result_class(‘DBIx::Class::ResultClass::HashRefInflator’);
 $rs->{attrs}{result_class} = ‘DBIx::Class::ResultClass::HashRefInflator’;
に変えて対処.
これまでここんとこでくねくねしてたので影響でかいわ.