Implementation of enum in migration about migrations

[mattvb91]

Can anyone else help with the regex in zephir to get just the values out of something like:

enum('test', 'test1', 'test(2)', 'test3')

[sergeyklay]

@mattvb91 I think for questions like this there is a separated regexp forums and the Zephir repo

[mattvb91]

Thanks @sergeyklay will check in there, thought it would be relevant here as its for the implementation of this issue 👍

[marhub]

Two months and nothing? C'mon!

[sergeyklay]

You can to do it. I'll try to review

[mattvb91]

phalcon/cphalcon#11368

[ChangePlaces]

Related to the:

• phalcon/cphalcon#10216
• phalcon/cphalcon#11139

[dronezzzko]

Any updates? 2 years have passed...

[sergeyklay]

@sergeysviridenko Could you please deal with this

[sergeysviridenko]

@dronezzzko I'll try to sort out with this as soon as possible.

[markhilton]

hello guys! any updated on fixing ENUM, maybe ETA?

[sergeysviridenko]

@markhilton Sorry, but at the moment there isn't any update. Enum field is specific field for MySQL db. Command migration creates files which can be use on different DB. For example - if we create migration with ENUM field, we won't use it on PostgreSQL db. Do you have any proposition about implementing this field?

[markhilton]

@sergeysviridenko nope, I just ported a database to Phalcon and noticed this error while doing migrations, so wanted to get an update to determine direction for my project. Thanks for taking time to answer, appreciate it!

[amnuts]

@sergeysviridenko I wouldn't say that they're specific to MySQL. PostgreSQL has enums, but beyond that others may not (eg, Oracle or SqlServer).

Perhaps you could generate a comment block for the specific db type on which the migration generation was run? Chances are someone is doing that because they're wanting to track the changes to their db structure and will retain that db type rather than running migration in order to change db type. So having the specific items in there - even if commented out - would be really handy for the user who can then just remove the comments.

For example:

    public function morph()
    {
        $this->morphTable('users', [
                'columns' => [
                    new Column(
                        'id',
                        [
                            'type' => Column::TYPE_INTEGER,
                            'unsigned' => true,
                            'notNull' => true,
                            'autoIncrement' => true,
                            'size' => 11,
                            'first' => true
                        ]
                    ),
                    /*
                     * MySQL DB migration
                     * This field type was automatically generated from a MySQL
                     * instance.  Using this to migrate to another database type
                     * is not guaranteed to work.  We have supplied a generic
                     * version below, or you can manually replace the generic
                     * field with the following if you remain on MySQL:
                     *
                     *    new Column(
                     *       'level',
                     *       [
                     *           'type' => Column::TYPE_ENUM,
                     *           'default' => "guest",
                     *           'notNull' => true,
                     *           'size' => 1,
                     *           'after' => 'id',
                     *           'value' => "'guest','user','super','admin'"
                     *       ]
                     *   )
                     *
                     */
                    new Column(
                        'level',
                        [
                            'type' => Column::TYPE_CHAR,
                            'default' => "none",
                            'notNull' => true,
                            'size' => 1,
                            'after' => 'id'
                        ]
                    )
                ],
                'indexes' => [
                    new Index('PRIMARY', ['id'], 'PRIMARY')
                ],
                'options' => [
                    'TABLE_TYPE' => 'BASE TABLE',
                    'AUTO_INCREMENT' => '',
                    'ENGINE' => 'InnoDB',
                    'TABLE_COLLATION' => 'utf8mb4_bin'
                ],
            ]
        );
    }

From the documentation it looks like you support some MySQL & PostgeSQL specific things such as onDelete/onUpdate, so it wouldn't be too far outside of that to put in column-specific stuff even without the comment.

[ChangePlaces]

Wow, I'm surprised this project is still going! I thought it was dead!

[amnuts]

@ChangePlaces hope not, because I've only just started to use Phalcon and its migrations! Does seem to have gone on for quite some time, though - a couple years at least? There seems to be an assumption that the tool can only be generic and support all databases and not give the specifics that the user may choose to use because it suits their needs. I'd rather it works so that I can track all the changes required in the db structure for my project, which runs on the db platform of my choosing, and will never be distributed - which means db-specific support where needed.

[beatwade]

@markhilton you can use connection with query in migration up method

[sergeyklay]

@sergeysviridenko Could you please deal with this

[sergeysviridenko]

Ok. I'll try to sort out.

[sergeysviridenko]

We'll try to implement in 4.0.x branch

[cryptolio]

Any quick fix for this stupid issue?

[sergeysviridenko]

@cryptolio there it can't be quick. We will try to implement it in 4.0.0 branch.

[maxttor]

What about SET type?

[Jeckerson]

Related #9

[Jeckerson]

Implemented in #55

[Jeckerson]

Released in v1.1.7