[PR #1495] wrong or wrong created source results in wrong default variable assignment #9554

New Issue

admin · 2026-01-22T16:04:40+01:00

admin commented

2026-01-22 16:04:40 +01:00

Original Pull Request: https://github.com/doctrine/orm/pull/1495

State: closed
Merged: No

This is a bit tricky, since the problem occures only in rare circumstances.

I rely heavily on the "database reverse engineering" function in symphony. So during development we modell our database and deploy it to the database server (debian/madiadb). Then I do an automated ORM descriptor creation and a automated entity file creation provided by this tool. DB -> table.orm.yml -> table.php
A default integer (1) value, defined in the database becomes a: default: '1'
Than the EntityGenerator reads the default: '1' in quotes from the yaml-definition and var_dumps it into the .php entity. As a result the default value becomes a wrong type and doctrine tells me it can't use this default value.
As a workaround I extra type cast the value depending on the defined type.
Would like to see this problem solved in a futher version. Anyways, I am happy with the way these processes work.

**Original Pull Request:** https://github.com/doctrine/orm/pull/1495 **State:** closed **Merged:** No --- This is a bit tricky, since the problem occures only in rare circumstances. I rely heavily on the "database reverse engineering" function in symphony. So during development we modell our database and deploy it to the database server (debian/madiadb). Then I do an automated ORM descriptor creation and a automated entity file creation provided by this tool. DB -> table.orm.yml -> table.php A default integer (1) value, defined in the database becomes a: default: '1' Than the EntityGenerator reads the default: '1' in quotes from the yaml-definition and var_dumps it into the .php entity. As a result the default value becomes a wrong type and doctrine tells me it can't use this default value. As a workaround I extra type cast the value depending on the defined type. Would like to see this problem solved in a futher version. Anyways, I am happy with the way these processes work.

admin added the pull-request label 2026-01-22 16:04:40 +01:00

admin closed this issue

2026-01-22 16:04:41 +01:00

admin referenced this issue

2026-01-22 16:11:39 +01:00

[PR #9554] Fixing typo #11702

Sign in to join this conversation.