Migrations do not work on Postgresql

[alxkolm]

Migrations do not work on Postgresql. Migration class m161004_132206_change_action_field

*** applying m161004_132206_change_action_field
    > alter column action in table tbl_audit_trail to ENUM('CHANGE', 'CREATE', 'DELETE', 'SET') NOT NULL ...Exception 'yii\db\Exception' with message 'SQLSTATE[42601]: Syntax error: 7 ERROR:  syntax error at or near "NOT"
LINE 1: ...ion" TYPE ENUM('CHANGE', 'CREATE', 'DELETE', 'SET') NOT NULL
                                                               ^
The SQL being executed was: ALTER TABLE "tbl_audit_trail" ALTER COLUMN "action" TYPE ENUM('CHANGE', 'CREATE', 'DELETE', 'SET') NOT NULL'

[alxkolm]

I think it is not necessary restrict column by ENUM type, because people want to set custom values in action

[uldisn]

Using ENUM is small optimization. My suggestion is in migration execute altering to ENUM only, if MySql.

 if ($this->db->driverName === 'mysql') {
}

[alxkolm]

But whenever I want set custom action I need alter column schema. It's very tedious.

[Sammaye]

I thought the enum change was a bad idea

On 1 November 2016 at 14:12, Kolmakov Alexey notifications@github.com
wrote:

But whenever I want set custom action I need alter column schema. It's
very tedious.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#24 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AATxnPbV77qNbQGQmM6PqrRs8P9p8WWxks5q50jOgaJpZM4KmBq0
.

[Sammaye]

Even for mysql users, this scenario is a common one whereby enum would cause too much application logic in the database. Current thinking is that the database should be dumb to the application rather than have two layers of validation at times, especially with very large tables spanning 30 million+ records, which audit tables can

[Sammaye]

I have decided to remove this for the time being 8e38c7f I think it is more trouble than it is worth

[alxkolm]

Fully agree