Moose のクラスを受講するのはちょっと面倒なようです。次に、DBIx::Classを使用して結果セットを取得し、結果セットをムース クラスに手動でマップします。
3 に答える
Moose クラスと DBIC スキーマの間を行ったり来たりする必要がある場合は、代わりにKiokuDBのような永続オブジェクト ストアを参照することをお勧めします。
特に既存のスキーマがある場合は、リレーショナル データベースの機能の一部が失われますが、データ ストアとオブジェクト モデル間の静かなマッピングを主な機能とする多くの機能が得られます。KiokuDB の DBI バックエンドは、おそらくこのトレードオフの最良の例です。データベースは高度に非正規化されていますが、それは効果的にキー ストアとして機能しているためです。
ただし、KiokuDB は、この種のデータ用に最適化されたストレージ エンジンと連携できます。これは、CouchDB や MongoDB など、現在注目されている「NoSQL」のいくつかをサポートしています。また、古いファンのお気に入りである BerkelyDB もサポートしています。
Kioku はすべての問題の解決策ではありませんが、パーキング モビリティがすべてのデータ ストレージをシームレスに処理するために使用され、非常に成功しています。
DBICでMooseを問題なく使用できます。実際、私はMooseX :: Declareの使用を楽しんでいます。これは、拡張構文が堅実なパブリックAPIを設計するときに非常に役立つことがわかったためです。
use MooseX::Declare;
class MyApp::Schema::Result::Geo::Division
extends MyApp::Schema::Result {
use Locale::Geocode::Division;
__PACKAGE__->table('division');
__PACKAGE__->add_columns(
fk_territory_id => {
data_type => 'char',
size => '36',
},
division_id => {
data_type => 'char',
size => '36',
},
code => {
data_type => 'varchar',
size => '5',
},
created => {
data_type => 'datetime',
set_on_create => 1,
},
);
__PACKAGE__->set_primary_key('fk_territory_id','division_id');
__PACKAGE__->uuid_columns('division_id');
__PACKAGE__->add_unique_constraint(['fk_territory_id','code']);
__PACKAGE__->belongs_to(
territory => 'MyApp::Schema::Result::Geo::Territory',
{'foreign.territory_id' => 'self.fk_territory_id'},
);
method as_geocode_division {
Locale::Geocode::Division->new($self->code);
}
__PACKAGE__->meta->make_immutable(inline_constructor => 0);
} 1;
Moose属性値をRose::DB :: Object値(プライベート属性に含まれるdbオブジェクトとobjectmanagerを使用)にマップするために、またはその逆を行うために、私が最近書いたものを正確に説明しているようです。私は当初、各Moose属性の周りにトリガーを使用して、Roseオブジェクトにすぐに書き込みましたが、後でそのアプローチを放棄し、必要な場合(つまり、->save()
操作時)にのみ値を遅延書き込みしました。いくつかのロールと、関連する属性の「私はテーブルフィールドです」を示す属性特性を自動的にインストールするsugarクラスを使用して実装しました。
しかし、私がしたことはしないでください。DBIx::Classを直接使用してください。次のメジャーバージョンはとにかくムースで書き直されているので、聞いています。