認識されていないテーブルが作成取得Doctrineはデータベース

Question

を構築するとき、私は、次のschema.ymlの

Proposition: 
    actAs: { Timestampable: ~ } 
    columns: 
    name: { type: string(255), notnull: true } 
    slug: { type: string(255), notnull: true, unique: true } 
    proposition_type_id: { type: integer, notnull: true } 
    icon: { type: string(255) } 
    overview: { type: string(4000) } 
    features: { type: string(4000) } 
    benefits: { type: string(4000) } 
    published: { type: boolean, notnull: true, default: 1 } 
    relations: 
    PropositionType: { onDelete: CASCADE, local: proposition_type_id, foreign: id } 
    Products: 
     class: Product 
     refClass: PropositionProduct 
     local: proposition_id 
     foreign: product_id 
     foreignAlias: PropositionProducts 

PropositionType: 
    columns: 
    name: { type: string(255), notnull: true } 

Review: 
    actAs: { Timestampable: ~ } 
    columns: 
    proposition_id: { type: integer, notnull: true } 
    review: { type: string(4000), notnull: true } 
    name: { type: string(255), notnull: true } 
    company: { type: string(255) } 
    published: { type: boolean, notnull: true, default: 1 } 
    relations: 
    Proposition: { onDelete: CASCADE, local: proposition_id, foreign: id } 

PropositionProduct: 
    columns: 
    proposition_id: { type: integer, primary: true } 
    product_id: { type: integer, primary: true } 
    relations: 
    Proposition: { onDelete: CASCADE, local: proposition_id, foreign: id } 
    Product: { onDelete: CASCADE, local: product_id, foreign: id } 

Product: 
    actAs: { Timestampable: ~ } 
    columns: 
    name: { type: string(255), notnull: true } 
    slug: { type: string(255), notnull: true, unique: true } 
    icon: { type: string(255) } 
    ataglance: { type: string(4000) } 
    idealfor: { type: string(4000) } 
    details: { type: string(4000) } 
    specsheet: { type: string(255) } 
    chart: { type: string(255) } 
    published: { type: boolean, notnull: true, default: 1 } 
    relations: 
    RelatedProducts: 
     class: Product 
     refClass: RelatedProduct 
     local: product_id 
     foreign: related_product_id 
     foreignAlias: RelatedProducts 

RelatedProduct: 
    columns: 
    product_id: { type: integer, primary: true } 
    related_product_id: { type: integer, primary: true } 
    relations: 
    Product: { onDelete: CASCADE, local: product_id, foreign: id } 
    Product: { onDelete: CASCADE, local: related_product_id, foreign: id } 

Segment: 
    actAs: { Timestampable: ~ } 
    columns: 
    name: { type: string(255), notnull: true } 
    slug: { type: string(255), notnull: true, unique: true } 
    published: { type: boolean, notnull: true, default: 1 } 
    relations: 
    Products: 
     class: Product 
     refClass: SegmentProduct 
     local: segment_id 
     foreign: product_id 
     foreignAlias: SegmentProducts 

SegmentProduct: 
    columns: 
    segment_id: { type: integer, primary: true } 
    product_id: { type: integer, primary: true } 
    relations: 
    Segment: { onDelete: CASCADE, local: segment_id, foreign: id } 
    Product: { onDelete: CASCADE, local: product_id, foreign: id } 

を持って、私は走った：

php symfony doctrine:build --all --and-load --no-confirmation 

をし、データベースが正常に組み込まれています。

しかし、なぜproposition_segmentテーブルが作成されていますか？私の理解から

CREATE TABLE `proposition_segment` (
    `segment_id` bigint(20) NOT NULL DEFAULT '0', 
    `product_id` bigint(20) NOT NULL DEFAULT '0', 
    PRIMARY KEY (`segment_id`,`product_id`), 
    KEY `proposition_segment_product_id_product_id` (`product_id`), 
    CONSTRAINT `proposition_segment_product_id_product_id` FOREIGN KEY (`product_id`) REFERENCES `product` (`id`) ON DELETE CASCADE, 
    CONSTRAINT `proposition_segment_segment_id_segment_id` FOREIGN KEY (`segment_id`) REFERENCES `segment` (`id`) ON DELETE CASCADE 
) ENGINE=InnoDB DEFAULT CHARSET=latin1; 

は私のスキームはSegmentとProductはSegmentProductテーブルを通して、多くの関係に多くの詳細を持っている必要があること。

同様に、PropositionおよびProductは、PropositionProductテーブルを介して多対多の関係を持ちます。

なぜDoctrineがproposition_segmentテーブルを作成しているのか理解できません。これ以外のデータベースは正しく見えます - テーブルproposition_productとsegment_productを期待通りに作成しました。

Symfonyによって生成された管理バックエンドを通じてデータを追加すると、proposition_segmentテーブルは空のままであり、誤って作成された疑いが増します。

Answer 1

greg0ireのリンクをありがとう、今日の数時間それを再生した後、私は新しい空のSymfonyプロジェクトを作成し、その中にscheme.ymlをロードすることにしました。それを構築した後、私は望んでいるデータベース構造を得ています！だから、スキームは実際には正しいと判明し、余分なテーブルを生成しているどこかのフォームクラスでなければなりません。私は、何が起こっているのかを調べるために、さらに掘り下げていくつもりです。私は別名を変更し、あなたの推薦に基づいて平等な巣関係を作成しました - ありがとうございます。

EDIT：

ビンゴ！私はlib/model /にいくつかのクラスが必要ではないことを発見しました。このフォルダを整理すると、生成される余分なテーブルが修正されました。私はDoctrineはconfig/doctrine/scheme.ymlファイルからのみ読み込みますが、あなたのモデルも読み込むと思いますが？ - もちろん、すべての例では、クラスを作成する2つの異なる方法が示されているためです。私はまだこれらのファイルが生成されたときは確かに正確ではないが、私は今から自分のモデルに注目するだろう。