web-dev-qa-db-ja.com

データベースの失敗-データベーススキーマが現在のマッピングファイルと同期していません

誰かが次のdoctrineスキーマ検証エラーメッセージを説明してください：

The error message returned by the schema validate function

これは、manyToMany関係の各エンティティのyaml ORM定義であり、 documentation のセクション5.9に沿って作成されています。

Rep\Bundle\ProjectBundle\Entity\User:
    type: entity
    table: User
    fields:
        id:
            id: true
            type: integer
            unsigned: true
            nullable: false
            generator:
                strategy: AUTO
        username:
            type: string
            length: 25
            fixed: false
            nullable: false
        salt:
            type: string
            length: 32
            fixed: false
            nullable: false
        password:
            type: string
            length: 40
            fixed: false
            nullable: false
        email:
            type: string
            length: 60
            fixed: false
            nullable: false
    manyToMany:
        roles:
            targetEntity: UserRole
            inversedBy: users
            joinTable:
                name: UserRoleLookup
                joinColumns:
                    user_id:
                        referencedColumnName: id
                inverseJoinColumns:
                    user_role_id:
                        referencedColumnName: id
    lifecycleCallbacks: {  }

そして、UserRoleの逆yaml構成：

Rep\Bundle\ProjectBundle\Entity\UserRole:
    type: entity
    table: UserRole
    fields:
        id:
            id: true
            type: integer
            unsigned: true
            nullable: false
            generator:
                strategy: AUTO
        name:
            type: string
            length: 50
            fixed: false
            nullable: false
    manyToMany:
        users:
            targetEntity: User
            mappedBy: roles
    lifecycleCallbacks: {  }

Userテーブルスキーマは次のとおりです。

CREATE TABLE `User` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `username` varchar(25) COLLATE utf8_unicode_ci NOT NULL,
  `salt` varchar(32) COLLATE utf8_unicode_ci NOT NULL,
  `password` varchar(40) COLLATE utf8_unicode_ci NOT NULL,
  `email` varchar(60) COLLATE utf8_unicode_ci NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

UserRoleテーブルスキーマ：

CREATE TABLE `UserRole` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(50) COLLATE utf8_unicode_ci NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

そして、UserRoleLookupスキーマ：

CREATE TABLE `UserRoleLookup` (
  `user_id` int(11) unsigned NOT NULL,
  `user_role_id` int(11) unsigned NOT NULL,
  PRIMARY KEY (`user_id`,`user_role_id`),
  KEY `user_role_id` (`user_role_id`),
  CONSTRAINT `userrolelookup_ibfk_2` FOREIGN KEY (`user_role_id`) REFERENCES `userrole` (`id`) ON DELETE CASCADE ON UPDATE CASCADE,
  CONSTRAINT `userrolelookup_ibfk_1` FOREIGN KEY (`user_id`) REFERENCES `user` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

ご覧のとおり、これは、ユーザーのロールまたは特定のユーザーロール内のユーザーのセットを指定するルックアップテーブルを備えた非常に単純なセットアップです。ただし、このイライラする同期エラーが発生します。この質問に簡潔に答えるここやオンラインでは何も読んでいません。この構成をそのままにしてこのエラーを無視しても安全かどうかを誰かが明確にできることを望んでいましたか？

symfonydoctrinedoctrine-ormyaml
12
Dan Belden

次のコマンドを実行して、データベースをダンプせずにSQLの違いを表示します。

php bin/console doctrine:schema:update --dump-sql

次のコマンドを実行して、変更を実行することもできます。

php bin/console doctrine:schema:update --force --full-database

Symfony2の場合は

php app/console doctrine:schema:update --force --full-database

27
Steve Tauber

symfony3の場合：

app/consoleはbin/consoleに、--full-databaseは--completeに変更されました

したがって、最終的なコマンドは次のようになります。

php bin/console doctrine:schema:update --force --complete --dump-sql
7
Stan Fad

簡単です。一部のフィールド、リレーション、エンティティなどは、データベーススキーマの列またはテーブルとしてまだ変換されていません。スキーマを更新すれば大丈夫です。

5
greg0ire

これに興味がある人のために、私のテーブルスキーマを再生成すると、次のルックアップスキーマが生成されました。

CREATE TABLE `UserRoleLookup` (
  `user_id` int(11) NOT NULL,
  `user_role_id` int(11) NOT NULL,
  PRIMARY KEY (`user_id`,`user_role_id`),
  KEY `IDX_4511E771A76ED395` (`user_id`),
  KEY `IDX_4511E7718E0E3CA6` (`user_role_id`),
  CONSTRAINT `FK_4511E7718E0E3CA6` FOREIGN KEY (`user_role_id`) REFERENCES `UserRole` (`id`),
  CONSTRAINT `FK_4511E771A76ED395` FOREIGN KEY (`user_id`) REFERENCES `User` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;\

Symfony2-doctrineバンドルは、私が投稿したスキーマからほとんど変更がないので、符号なし整数の大ファンではないと思います。とにかく、問題は解決しました。

3
Dan Belden

私も同じ問題を抱えてる。その上、走っているとき

php bin/console doctrine:schema:update --dump-sql

すでにSQLを実行したかどうかに関係なく、常に同じSQLが表示されます。上記のコマンドは、データベーススキーマと現在のエンティティメタデータの実際の違いを検出できないようです。また、この種の問題が、使用したデータベースに何らかの形で関連していることも確認します。 少なくともMySQL 5.7.25ではそのような問題はないので、MariaDB 10.2.24。詳細についてはこちらを確認してください： https://github.com/symfony/symfony/issues/27166#issue-320494745

P.S. MariaDBは、「インデックスキーの長さ767バイト」のような他の問題を引き起こします。それが悪いという意味ではありません。しかし、3年前に初めてMariaDBを使用することにしたとき、Oracleが買収したばかりのMySQLと比較してどれほど優れているかを投稿/ニュースで思い出してください。そして、MySQLが異なり、その後パニックになるというニュース....（個人的な意見）

0
Nero

php bin/console doctrine：schema：update--dump-sql動作する可能性があります問題が修正されました

0
jack lee