-
Notifications
You must be signed in to change notification settings - Fork 2.5k
Description
Bug Report
| Q | A |
|---|---|
| Version | 3.6.0 |
| Previous Version if the bug is a regression | DBAL < 4.0 |
Summary
Previously discussed in Migrations doctrine/migrations#1518
When having ID in a trait like Int64Identifier and using it in the Entity as the first thing before any other columns, it somehow ends in the middle of the SQL.
trait Int64Identifier
{
#[Id, GeneratedValue, Column(type: Types::BIGINT, options: ['unsigned' => true])]
private(set) int $id;
}
#[Entity]
class Timezone
{
use Int64Identifier;
#[Column(unique: true)]
private(set) string $name;
}SQL:
CREATE TABLE timezone (name VARCHAR(255) NOT NULL, id INT UNSIGNED AUTO_INCREMENT NOT NULL, UNIQUE INDEX UNIQ_3701B2975E237E06 (name), PRIMARY KEY (id)) DEFAULT CHARACTER SET utf8mb4 COLLATE `utf8mb4_unicode_520_ci`I created some demo here https://github.com/rixafy/doctrine-bad-column-order
For some reason, when using DBAL < 4.0 this wasn't an issue, not sure why, now when I generate migration, ID column is somewhere in the middle or at the end of the SQL for creating table.
I did some debugging and it seems that DBAL does not modify the order at all, it respects the order from ORM where AnnotationDriver scans the entity, if we read properties via reflection, PHP cannot guarantee the order, because trait is merged with entity during runtime and the fields are added after all other fields probably, there is no easy way around that (we would have to read the PHP file and tokenize it if we wanted correct column order).
So I wonder if I could edit AnnotationDriver to always add ID column first to the medatada and then rest of the columns, so ID is always first thing in the table, I usually don't mind the column order, but when ID is at the end of big table, it's annoying.. and I always have to edit SQLs manually, when starting a new project, this can be time consuming.