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?

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).

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.

Please make sure this new behavior is covered by a functional test as well.

If I look at your original PR the only functional test is for MySql https://github.com/doctrine/dbal/pull/6536/files#diff-5c5395e4aacfd52ec445d9845a95e2fd534deeaa427ad12b95ffab58127ceffaR16 which is not concerned here.

I'm basically doing the same than #6579 which didn't add functional tests.

I feel like the changed are already 100% covered by the unit test.

I'm not sure which functional test should be added ? @derrabus

Thanks. The documentation needs a little update as well, I suppose.

Does 809e7d7 is enough @derrabus or you want something else (any suggestion welcomed).

Thank you!

Thanks to you too !

Also, I have two extra question @derrabus ;

• could you give your opinion on Remove internal from comparator-related classes constructor #7038 ?
• when do you decide to release a new minor version ?

Thanks and good weekend

I've seen that one and it's on my list. 🤞🏻

We don't have a fixed schedule for releases. We do releases as we see fit.