错误:SQLSTATE [HY000]:常规错误:1215无法在Phalcon中添加外键约束

时间:2022-10-14 13:49:24

I'm trying to run a migration with Phalcon (Devtools 2.0.10) but it keeps complaining about ERROR: SQLSTATE[HY000]: General error: 1215 Cannot add foreign key constraint

我正在尝试使用Phalcon(Devtools 2.0.10)运行迁移,但它一直在抱怨ERROR:SQLSTATE [HY000]:一般错误:1215无法添加外键约束

I've run migrations with this last week and they all worked fine, not sure what is different now. I've scrapped the database, reinstalled mysql, recreated the database, still does the same thing.

我上周进行了迁移,他们都运行良好,不知道现在有什么不同。我已经废弃了数据库,重新安装了mysql,重新创建了数据库,仍然做同样的事情。

The problem seems to be related to foreign keys in general and not specifically these ones. It starts by complaining about a specific model, so I removed the references statement just to see, and it stops at the next foreign key declaration and so on. The engine is set to InnoDB, the types of the keys match and it runs fine on my colleague's machine so I'm sure it's not a syntax problem but rather something specific about SQL (server)

问题似乎与外键一般有关,而不是具体的这些。它首先抱怨一个特定的模型,所以我删除了引用语句只是为了看,它停在下一个外键声明等等。引擎设置为InnoDB,键的类型匹配,它在我同事的机器上运行正常,所以我确定它不是语法问题,而是SQL(服务器)的特定内容

class ModuleTranslationsMigration_100 extends Migration
{

public function morph()
{
$this->morphTable('', array(
...
'references' => array(
    new Reference(
        'module_translations_ibfk_1',
        array(
            'referencedSchema' => 'learning',
            'referencedTable' => 'modules',
            'columns' => array('module_id'),
            'referencedColumns' => array('id')
        )
    ),
    new Reference(
        'module_translations_ibfk_2',
        array(
            'referencedSchema' => 'learning',
            'referencedTable' => 'languages',
            'columns' => array('language_id'),
            'referencedColumns' => array('id')
        )
    )
),
...

class LanguagesMigration_100 extends Migration
{

public function morph()
{
    $this->morphTable('languages', array(
            'columns' => array(
                new Column(
                    'id',
                    array(
                        'type' => Column::TYPE_CHAR,
                        'notNull' => true,
                        'size' => 2,
                        'first' => true
                    )
                ),
...

class ModulesMigration_100 extends Migration
{
    public function morph()
    {
        $this->morphTable('modules', array(
                'columns' => array(
                    new Column(
                        'id',
                        array(
                            'type' => Column::TYPE_INTEGER,
                            'unsigned' => true,
                            'notNull' => true,
                            'autoIncrement' => true,
                            'size' => 10,
                            'first' => true
                        )
                    ),
    ...

1 个解决方案

#1


0  

The problem was foreign keys at the SQL level, not a problem with syntax or the DDL per se. It seems that Phalcon will create the tables either in alphabetical file order in /migrations and doesn't take into account the table structure.

问题是SQL级别的外键,而不是语法或DDL本身的问题。似乎Phalcon将在/ migrations中按字母顺序文件顺序创建表,而不考虑表结构。

Executing

执行

mysql> SET GLOBAL FOREIGN_KEY_CHECKS=0;

mysql> SET GLOBAL FOREIGN_KEY_CHECKS = 0;

before running the migration does the trick, before setting it back of course.

在运行迁移之前完成这一操作,然后再将其设置回来。

I'm not sure it was necessary in this case but I removed all mysql rpms, deleted the /var/lib/mysql directory before starting over.

我不确定在这种情况下是否有必要但我删除了所有mysql rpms,在重新开始之前删除了/ var / lib / mysql目录。

#1


0  

The problem was foreign keys at the SQL level, not a problem with syntax or the DDL per se. It seems that Phalcon will create the tables either in alphabetical file order in /migrations and doesn't take into account the table structure.

问题是SQL级别的外键,而不是语法或DDL本身的问题。似乎Phalcon将在/ migrations中按字母顺序文件顺序创建表,而不考虑表结构。

Executing

执行

mysql> SET GLOBAL FOREIGN_KEY_CHECKS=0;

mysql> SET GLOBAL FOREIGN_KEY_CHECKS = 0;

before running the migration does the trick, before setting it back of course.

在运行迁移之前完成这一操作,然后再将其设置回来。

I'm not sure it was necessary in this case but I removed all mysql rpms, deleted the /var/lib/mysql directory before starting over.

我不确定在这种情况下是否有必要但我删除了所有mysql rpms,在重新开始之前删除了/ var / lib / mysql目录。