mirror of
https://github.com/doctrine/orm.git
synced 2026-03-24 06:52:09 +01:00
More mapping errors when upgrading to 2.17.0 (but still exists) #7268
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 @paullallier on GitHub (Dec 4, 2023).
BC Break Report
Summary
On upgrade, I've stated to get schema mapping error messages that I wasn't getting before.
This looks related to https://github.com/doctrine/orm/issues/11063, but isn't fixed in the latest release. I'm only using ORM to keep keep my schema aligned with my API docs and not for DB persistence - that's all in raw DBAL commands - so it might be that my entity definition wasn't valid before and I just got away with it. Sorry if I'm just doing something stupid.
Previous behavior
symfony console doctrine:schema:validatereports no issuesCurrent behavior
symfony console doctrine:schema:validatereports many similar issues including:How to reproduce
My Logo entity has a
usagefield that I'm storing as an integer and serving to / from the user as a string (essentially an enum handled with I normalise/denormalise).The JobItemList should just be a ManyToOne mapping (made slightly more complex by having some of the properties in abstract cases):
I'm struggling to see why this worked before and doesn't now - sorry.
I don't think it's relevant, but I'm using MySQL 8.0.28
@greg0ire commented on GitHub (Dec 4, 2023):
It does not look related to #11063, but to https://github.com/doctrine/orm/issues/10661
I think your entity definition wasn't really valid before and you got away with it.
🤨 what?
@paullallier commented on GitHub (Dec 4, 2023):
Thanks Grégoire.
Sounds like I need to redesign my entities so that (for example) I have a usage_int in the database and a usage (string) that the end users sees/supplies. (Or use an enum, but I really don't like enum limitations in MySQL).
I don't at all understand why the case with the ManyToOne relationship is unhappy, but it sounds like that's a Symfony Slack #doctrine discussion rather than a Github one, if it's my error rather than a bug.
Maybe I used the wrong terminology (or I'm just doing something crazy). I'm using Doctrine migrations to map my entities to my DB schema in the hope that this helps keep the DB design aligned with the auto-generated (Api-platform) docs. But my DB isn't entirely CRUD and doesn't really fit into the ORM model, so I'm using DBAL to commit and retrieve data instead of letting ORM do it for me. The detail also might not be for here - I'm very happy to describe it on Slack if you want to have a good laugh at me (but I suspect you might have better things to do).
If you're happy that this is "not a bug" feel free to close it. It's not critical for me at the moment and might always remains as just an annoying warning. Perhaps someone else will complain if I turn out not to be the only person having the issue.
@greg0ire commented on GitHub (Dec 4, 2023):
Oh OK, for a moment, I thought you had no db at all and had implemented some kind of dbal driver that resulting in calls to APIs. I understand better now. Nothing wrong with your usage of the ORM.
Regarding the
ManyToOnerelationship, I'm not sure this part is valid:What does it mean to have
$itemmapped to a column withColumn, and then to also have it mapped to a relationship withManyToOne?@paullallier commented on GitHub (Dec 4, 2023):
It means I've failed to notice that I've essentially defined the Column twice for some reason. And when I fix it by removing the
#[ORM\Column]attribute, the error message goes away, foreign key that I was missing appears, and I feel like a bit of an idiot. Thank you very much!