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

[octaharon]

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)

[lcobucci]

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

[octaharon]

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.