15

バックグラウンド

「コア」バンドルがエンティティ、関係、およびフィールドを定義するように構造化された Symfony 2 を使用してアプリケーションを開発しています。他のバンドルは、いわゆる「子」バンドルと呼ばれる継承によってコア機能を特殊化できます。

Doctrine 2 アノテーションは、「パッケージ」と呼ばれるコア エンティティを定義するために使用されています。「パッケージ」は、建築設計と土地を結び付けるもので、基本的には家と土地のパッケージです。例をより基本的な形式に切り戻したので、以下の例では Land と ChildLand の定義は見つかりませんが、同様の方法で実装されていると推測できます。

アップデート

FreeNode の #symfony チャンネルのユーザーによると、これは app/console コマンドが単純にドクトリン コンソールを呼び出すため、ドクトリンの問題です。私はドクトリン2.3を使用しています。

シナリオを視覚化するのに役立つ問題を引き起こす一般的な状況を示す図を次に示します。

(フルサイズの画像への imgur リンク) 型ヒンティング コントラクト違反

また、doctrine の問題トラッカーに関するバグ レポートへのリンクは次のとおりです: http://www.doctrine-project.org/jira/browse/DDC-2605

更新 2 - より詳細な ERD

エンティティ間の関係の構造が疑問視されているため、以下は実装しているデータ構造のより良い例です。

主な要件は、エンティティとフィールドの共有セットを提供するコア クラスを持つことです。カンパニー バンドルの子クラスは、これらのコア クラスを拡張します。

私たちはEAVを詳細に検討しましたが、そのアプローチでは、現在のビジネス要件を満たすのではなく、EAVデータを管理するためのプラットフォームとツールを作成することに多くの時間を費やすことになり、ドクトリンを使用してエンティティを管理することはできませんそれらはデータベースなどで定義されます。

時間が経ち、この問題をよりよく理解できるようになると、doctrine の CLI ツールによって生成された getter と setter が、後述のようにタイプ ヒンティング コントラクトを破るために唯一の問題があるように見えます。これらの問題を手動で修正すると、この構造は完全に機能します。

(フルサイズの画像への imgur リンク) 詳細なデータ構造

CLI ツールを使用したエンティティの生成

それで、最初はコマンドラインツールを使用しました...

> app/console doctrine:generate:entity

...基本的なフィールド マッピングを使用してエンティティ スタブを生成し、土地への関係を手動で追加しました (ツールは関係をサポートしていないようです)。

結果のコードは次のとおりです。

コア パッケージ エンティティ: http://pastebin.com/3ujPT1mJ

子パッケージ エンティティ: http://pastebin.com/sjAB0XJ2

ゲッターとセッターの生成

次に、以下を実行してゲッターとセッターを生成します。

> app/console doctrine:generate:entities CompanyCoreBundle

> app/console doctrine:generate:entities CompanyChildBundle

これにより、コアおよび子エンティティの定義が自動的に変更されます。

コア パッケージ エンティティ: http://pastebin.com/kfQRxcnm

子パッケージ エンティティ: http://pastebin.com/UdiPP9xX

問題!

したがって、問題の核心は次のとおりです。Core および Child バンドルの setLand 関数を比較すると、宣言が異なることがわかります。

public function setLand(\Company\CoreBundle\Entity\Land $land = null)
public function setLand(\Company\ChildBundle\Entity\ChildLand $land = null)

エラー:(

残念ながら、型ヒントが異なると、PHP の厳密なエラーが発生します。次に例を示します。

PHP Fatal error:  Class 'Symfony\Component\Debug\Exception\ContextErrorException' not found in ... Company/ChildBundle/Entity/ChildPackage.php on line ...

Runtime Notice: Declaration of ... should be compatible with ... in ... line ...

エラーの原因

なぜこれが問題なのかを調査した後、いくつかの場所で、サブクラスで型ヒントを変更すると型ヒント コントラクトが壊れることを読みました (この投稿を参照してください:抽象クラスを拡張するときに、型ヒントを子孫クラスに再定義する方法はありますか? ? )。

オプション?

明白ではあるが理想的ではないオプションがいくつかあります。

  • 私は厳格な通知を非常に簡単に抑制することができますが、私の開発マネージャーは、CI プロセスでスノーフレーク例外を作成しなければならないという可能性を嫌がります。
  • doctrine が生成するコードを手動で編集して、すべての型ヒントを削除したり、子クラスの型ヒントが親クラスと同じであることを確認したりできます。これを行うとコードが機能しますが、これを管理するためのスクリプトをいくつか書かない限り、面倒だと思います。
  • コマンドラインツールを使用して、エンティティとサブエンティティを手動で手作りすることはできません. 私はむしろスクリプトでこれを自動化できると思います:(

私の質問!!!(最後に)

私の質問は、コマンド ライン ツールを使用して、ここでやろうとしていることを実行することは可能ですか? 理想的には、doctrine コンソール コマンドを実行してエンティティ スタブと getter および setter を生成し、サブクラスの型ヒントを手動で修正する必要がないようにしたいと考えています。これが簡単に達成できない場合、次善の選択肢は何ですか?

感謝

ありがとう!

4

1 に答える 1