Use provided length for enum type if given for non-mysql platform

[VincentLanglet]

Q	A
Type	improvement ? fix ?
Fixed issues

Summary

When a Type Enum is used AND a length

#[ORM\Column(name: 'role', type: Types::Enum, length: 50)

the length is not used at all when generating the sql.

This makes sens for MysqlPlatform which list all the possible case, but for non-mysql platform it could be a way to reserved more length in advance in order to avoid futur ALTER TABLE.
The current strategy is too look at the max length of all the existing values, which means that adding new enum values might trigger every time an ALTER table just to use a bigger length.

[morozov]

but for non-mysql platform it could be a way to reserved more length in advance in order to avoid futur ALTER TABLE.

What's the problem with future ALTER TABLE? On MySQL, if you add a new element to the enum, there will be an ALTER TABLE. Why avoid it on other platforms?

[VincentLanglet]

What's the problem with future ALTER TABLE?

First, it feels odd to have

#[ORM\Column(name: 'role', type: Types::Enum, length: 50)

not throwing an error if the length is not used at all.

Then, running ALTER TABLE query might be slow if you already have something like million or billion of rows, no ?
It could be from Varchar(5) to VarChar(10) when adding an enum value or worst from VarChar(10) to VarChar(5) when removing one (And I assume the database will need to check every existing row length).
So how about allowing to avoid such extra query ?

If someone wants futur ALTER TABLE, he just have to not provide any length in the column.
If someone wants to reduce futur ALTER TABLE, that will be the purpose of the length column.

On MySQL, if you add a new element to the enum, there will be an ALTER TABLE. Why avoid it on other platforms?

Mysql use specific syntax ENUM() which really restrict the possible values we can save in the database, so there is a real benefit updating the table. For other Platform there is no such specific syntax and doctrine rely on string field ; so there is no benefit updating every time the column definition.

For example with Postgres, we can define constraint check

ALTER TABLE foo ADD CONSTRAINT foo_check CHECK (bar IN ('A', 'B', 'C'))

and when changing the enum, only the constraint is needed to be updated, but there is no gain to update the field length everytime (if we create the field with a bigger length first time).

[derrabus]

First, it feels odd to have

#[ORM\Column(name: 'role', type: Types::Enum, length: 50)

not throwing an error if the length is not used at all.

It will also not throw if you assign a precision to that column. 🤷🏻‍♂️

Then, running ALTER TABLE query might be slow if you already have something like million or billion of rows, no ?

The column has variable length already, so the operation of changing the maximum column length itself is cheap. However, if the column is part of an index, that index might need to be rebuilt which can be expesinve.

It could be from Varchar(5) to VarChar(10) when adding an enum value or worst from VarChar(10) to VarChar(5) when removing one (And I assume the database will need to check every existing row length). So how about allowing to avoid such extra query ?

Yeah, allowing to specify the length of the varchar field is reasonable. I think, we should allow it.