DDL generated repeatedly on schema:update with same Schema, if "default" value is missing #5784

New Issue

admin · 2026-01-22T15:17:46+01:00

admin commented

2026-01-22 15:17:46 +01:00

Originally created by @octaharon on GitHub (Nov 23, 2017).

That seems quite a minor bug but still can cause some problems, esp. when using Migrations bundle

So if an entity has a field described like that
@ORM\Column(name="field", type="integer", length=8, options={"default"})

it doesn't cause any errors both on schema:update or schema:validate, but they repeatedly report a difference in that field, and "update" tries to perform the following query
ALTER TABLE some_table CHANGE field field INT NOT NULL;
and it will generate it continiously on every update or migration:diff despite nothing changes

if "default" or the whole "options" property is removed, everything is working as expected
Same applies if default value is actually specified and valid:
@ORM\Column(name="field", type="integer", length=8, options={"default": 1 })

So the issue is only due to incorrect field specification, but it's never stated that it's incorrect. Another question is how the Schema tool should behave in this particular scenario. I would assume that "default" is NULL, and if the column has nullable=false at the same time than it should cause a validation error at least.

Doctrine version used:
"doctrine/common": "^2.8", "doctrine/dbal": "^2.6", "doctrine/doctrine-bundle": "^1.7", "doctrine/doctrine-cache-bundle": "^1.2", "doctrine/doctrine-migrations-bundle": "^1.3", "doctrine/orm": "^2.5",

RDBMS affected (which I have tested):

MySQL 5.7
MariaDB 10.1
MariaDB 10.2 (which also has a bunch of other issues but not relevant)

Originally created by @octaharon on GitHub (Nov 23, 2017). That seems quite a minor bug but still can cause some problems, esp. when using Migrations bundle So if an entity has a field described like that `@ORM\Column(name="field", type="integer", length=8, options={"default"})` it doesn't cause any errors both on schema:update or schema:validate, but they repeatedly report a difference in that field, and "update" tries to perform the following query `ALTER TABLE some_table CHANGE field field INT NOT NULL;` and it will generate it continiously on every update or migration:diff despite nothing changes if "default" or the whole "options" property is removed, everything is working as expected Same applies if default value is actually specified and valid: `@ORM\Column(name="field", type="integer", length=8, options={"default": 1 })` So the issue is only due to incorrect field specification, but it's never stated that it's incorrect. Another question is how the Schema tool should behave in this particular scenario. I would assume that "default" is NULL, and if the column has `nullable=false ` at the same time than it should cause a validation error at least. Doctrine version used: ` "doctrine/common": "^2.8", "doctrine/dbal": "^2.6", "doctrine/doctrine-bundle": "^1.7", "doctrine/doctrine-cache-bundle": "^1.2", "doctrine/doctrine-migrations-bundle": "^1.3", "doctrine/orm": "^2.5", ` RDBMS affected (which I have tested): * MySQL 5.7 * MariaDB 10.1 * MariaDB 10.2 (which also has a bunch of other issues but not relevant)

admin commented

2026-01-22 15:17:46 +01:00

@lcobucci commented on GitHub (Nov 24, 2017):

@octaharon this is a DBAL issue, and it looks like it's related to https://github.com/doctrine/dbal/pull/2850 and https://github.com/doctrine/dbal/pull/2825. Could you please check if these PRs fixes your problem (and maybe move this discussion to DBAL instead)?

@lcobucci commented on GitHub (Nov 24, 2017): @octaharon this is a DBAL issue, and it looks like it's related to https://github.com/doctrine/dbal/pull/2850 and https://github.com/doctrine/dbal/pull/2825. Could you please check if these PRs fixes your problem (and maybe move this discussion to DBAL instead)?

admin commented

2026-01-22 15:17:47 +01:00

@octaharon commented on GitHub (Nov 27, 2017):

No, I believe it's not related, since I can reproduce it on MySQL server as well. Despite that I've tried both PR's - didn't change anything regarding the issue mentioned.
My point was not that the behaviour itself should be considered "invalid", it's just neither documented nor validated to declare a field with options={"default"}. So it's not really clear how it SHOULD behave with things like this. And in my particular case it was quite a nuisance to locate the reason my migrations failed, cause the aformentioned declaration causing that was clearly just a typo, which, if you ask me, should invoke a schema validation error at least.

@octaharon commented on GitHub (Nov 27, 2017): No, I believe it's not related, since I can reproduce it on MySQL server as well. Despite that I've tried both PR's - didn't change anything regarding the issue mentioned. My point was not that the behaviour itself should be considered "invalid", it's just neither documented nor validated to declare a field with `options={"default"}`. So it's not really clear how it SHOULD behave with things like this. And in my particular case it was quite a nuisance to locate the reason my migrations failed, cause the aformentioned declaration causing that was clearly just a typo, which, if you ask me, should invoke a schema validation error at least.

admin referenced this issue

2026-01-22 16:05:14 +01:00

[PR #5785] Fix getJoinTableName to care about schema emulation #9723

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#5784