1

Doctrine2 で、複雑な SQL クエリの結果に基づいて計算されたエンティティを作成する方法はありますか?

背景:

私が取り組んでいるアプリケーション (プロジェクトに参加する前に存在していた) には、次の概念があります: 属性 (属性に属し、多くの属性を持ち、属性をオーバーライドします)属性）

その考えは、catalogItem には独自の階層があり、現在は最大 4 レベルの深さまであるということです。各 catalogItem はその親の属性を継承しますが、これらの属性 (独自の階層も持つ) はいつでもオーバーライドできます。このオーバーライドされた階層は、直接の catalogItem とその子によって使用され、オーバーライドを作成する同じ機能が存在します。

その結果、計算された最終結果を常に確認する必要があるため、直接関連付けの典型的な構造はここではほとんど役に立ちません。

したがって、私の問題は、これらの計算結果をDoctrine2に注入できるようにしたいということです。これは、標準エンティティとして使用でき、リレーションなどを通常どおりトラバースする機能です。

パフォーマンスが低下するため、これは MySQL ビューとして実行できません。さらに、計算結果を作成するクエリはかなり複雑であり、パフォーマンスのために、すべてのフィルタリング (たとえば、X catalogItem による) は、第 3 レベルのネストされたサブクエリとトップレベルのクエリの両方で発生し、サブクエリの存在そのものでも発生します。通常の MySQL ビューは直接互換性がないことを意味します (回避策はありますが)。

質問:

「テーブル」が存在する代わりに、実際の MySQL クエリが存在し、サブクエリとして実行されるエンティティを Doctrine2 で作成できるようにしたいと考えています。Doctrine2 で、私が説明しているようなことを達成する方法をまだ見ていません。誰かが同様の結果を達成するための解決策または回避策を提示できることを願っていますか?

4

1 に答える 1

1

いいえ、Doctrine ORM でこの種のロジックを処理する方法はありません。ORM は、(エンティティの定義から) 関連付けられ、一意の識別子を持つ静的に型付けされたエンティティを考慮します。

また、ORM は型キャストを処理できないため、これらのエンティティの値と型は動的に変更されるべきではありません。

あなたができることは次のとおりです。

  1. mysql レベルのビューを定義する
  2. としてマークされたエンティティを作成します@Entity(readOnly=true)。これは、フラッシュ時に ORM によって無視されます

このようにして、ORM は通常のpersistersを使用してエンティティからデータを読み取ることができ、関連付けでオブジェクトの識別子を使用できるようになります。

エンティティ タイプが計算される場合は、ビューで識別子列を使用して単一テーブルの継承をエミュレートすることを検討してください。

于 2013-03-24T16:17:59.860 に答える