mirror of
https://github.com/doctrine/orm.git
synced 2026-03-23 22:42:18 +01:00
Using nonInsertable/nonUpdateable columns with JOINED inheritance type triggers SQL error
#6923
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @bordgab on GitHub (Feb 3, 2022).
Bug report
JoinedSubclassPersister::getInsertColumnList()does not take care ofnotInsertable/notUpdateableproperty of field mapping in parent class, therefore the column(s) appears in INSERT/UPDATE statement.This wrong behaviour generates a
DriverExceptionwith the following message, becauseBasicEntityPersister::prepareUpdateData()(correctly) does not provide the appropriate changeset:ORM version: 2.11
Follow up to https://github.com/doctrine/orm/pull/9118
@derrabus commented on GitHub (Feb 4, 2022):
ORM 2.9 is not maintained anymore. Can you please try to reproduce your problem with a recent release? If this issue still occurs, please provide steps to reproduce your problem.
@beberlei commented on GitHub (Feb 4, 2022):
This must be 2.11 since it uses a new feature
@bordgab commented on GitHub (Feb 4, 2022):
Thanks for the version fix, I overlooked the version number....
@curry684 commented on GitHub (Oct 14, 2022):
I'm experiencing a related issue in ORM 2.13.3, I think it's strongly related based op superficial debugging.
I have the following field in an abstract entity used in single table inheritance:
The
insertableproperty is properly processed, the field is not added to theINSERTwhen flushing. However thegenerated: 'ALWAYS'should trigger aSELECTright after, to fill the generated field. This is not happening, causing the field to remain uninitialized until the next request.I suspect it's caused by the derived class not properly being aware that its base class contains the generated field.
@hakai commented on GitHub (Feb 7, 2023):
I'm getting the same issue in doctrine-bundle:2.8.2 and orm 2.14.0, using a MySQL database. Apparently the code that picks up the parameters respects the insertable flags, but the code that creates the SQL query does not. Minimal example:
src/Entity/AbstractUser.php:
src/Entity/Customer.php:
src/Controller/DebugController.php:
Outcome after executing the route /debug (with
dd($this->sql, $this->params);invendor/doctrine/dbal/src/Statement.php::execute($params)@187):Expected outcome:
EDIT: The updatable flag (at least in my tests) worked as expected. It will cause an empty transaction if you only change the value of the updatable:false field, but that is acceptable imo.
@mrVrAlex commented on GitHub (Aug 22, 2023):
@derrabus You can close this due to https://github.com/doctrine/orm/pull/10598
Now (in v2.16.x) this should be working as expected.