13

誰かが次の教義スキーマ検証エラーメッセージを説明できますか?

スキーマ検証機能によって返されるエラーメッセージ

これは、manyToMany関係の各エンティティのyaml ORM定義であり、ドキュメントのセクション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;

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

4

7 に答える 7

33

次のコマンドを実行して、データベースをダンプせずに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

于 2013-05-14T19:11:27.327 に答える
8

Symfony3の場合:

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

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

php bin/console doctrine:schema:update --force --complete --dump-sql
于 2017-01-26T14:15:49.877 に答える
5

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

于 2012-12-02T17:46:19.583 に答える
3

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

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

于 2012-12-02T22:05:18.750 に答える
0

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

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

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

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

于 2019-11-11T06:08:48.733 に答える
0

これらのコマンドを実行している場合:

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

生成されたSQLは新しいエンティティを作成しません(CREATE TABLEは作成されません)。マッピングに問題がないかどうかを確認することをお勧めします。私の場合、これをマッピングに入れるのを忘れました。

 * @ORM\Entity
于 2020-07-27T09:48:23.043 に答える
-1

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

于 2017-08-18T03:10:23.947 に答える