9

任意の結果クラス MySchema::Result::Foo (Moose/MooseX::nonmoose を使用するデフォルトのスキーマ ローダー生成構文から構築)

BUILDARGS メソッド ラッパーを追加して、行のコンストラクター データを次のようにサニタイズすると、次のようになります。

package MySchema::Result::Foo;
use Moose;
use MooseX::NonMoose;
[etc ..]

around 'BUILDARGS' => sub {
   my $orig = shift;
   my $class = shift;
   delete $_[0]->{not_a_real_column};
   return $class->$orig(@_);
};

スキーマを直接使用する場合に機能します。たとえば、次は期待どおりに動作します: ->new が呼び出される前に、real_column=>'value' と not_a_real_column が削除された新しい行オブジェクトが作成されます。

use MySchema;
my $s = MySchema->connect('dbi:blahblahblah');
$s->resultset('Foo')->new({ real_column=>'value', not_a_real_column=>'some other thing' }); #win

ただし、Catalyst::Model::DBIC::Schema を介して同じスキーマを使用する場合、順序は異なります。not_a_real_column が無効であるため、新しい Foo 行オブジェクトを作成しようとすると、次のように失敗します。つまり、new への引数は、->new が呼び出される前に BUILDARGS を介して実行されません。

$c->model('MySchemaModel')->resultset('Foo')->new({ real_column=>'value', not_a_real_column=>'some other thing' }); #fails

興味深いことに、'BUILDARGS' => sub{} の代わりに 'new' => sub{} をラップすると、動作はどちらの場合も同じで、正常に動作しますが、Moose のドグマでは決して混乱しないように述べられています。新着。

なぜこれが当てはまるのか、またはより良い方法があるかどうかを理解するのを手伝ってくれる人はいますか?

4

1 に答える 1