More mapping errors when upgrading to 2.17.0 (but still exists) #7268

Closed
opened 2026-01-22 15:48:37 +01:00 by admin · 4 comments
Owner

Originally created by @paullallier on GitHub (Dec 4, 2023).

BC Break Report

Q A
BC Break yes
Version Upgrading from 2.16.3 --> 2.17.0 (but still an issue in 2.17.1)

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:validate reports no issues

Current behavior

symfony console doctrine:schema:validate reports many similar issues including:


 [FAIL] The entity-class App\Entity\Organisation\Logo mapping is invalid:
 * The field 'App\Entity\Organisation\Logo#usage' has the property type 'string' that differs from the metadata field type 'int' returned by the 'integer' DBAL type.

 [FAIL] The entity-class App\Entity\Job\JobItemList mapping is invalid:
 * The field 'App\Entity\Job\JobItemList#item' has the property type 'App\Entity\Job\GenericJobItem' that differs from the metadata field type 'int' returned by the 'integer' DBAL type.

How to reproduce

My Logo entity has a usage field that I'm storing as an integer and serving to / from the user as a string (essentially an enum handled with I normalise/denormalise).

use Doctrine\ORM\Mapping as ORM;

#[ORM\Entity]
class Logo
{
    // Currently only one usage - but we might add more in future
    public const usages = ['document' => 1];

    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column]
    private ?int $id = null;

    #[ORM\Column(type: 'integer', nullable: false)]
    private ?string $usage = null;

<etc>

The JobItemList should just be a ManyToOne mapping (made slightly more complex by having some of the properties in abstract cases):

use Doctrine\ORM\Mapping as ORM;

#[ORM\Entity]
class JobItemList extends GenericJobItemList
{
    #[ORM\Id]
    #[ORM\Column]
    #[ORM\ManyToOne(targetEntity: JobItemListNumber::class)]
    #[ORM\JoinColumn(name: 'id', referencedColumnName: 'id', nullable: false)]
    protected ?int $id = null;

    #[ORM\Column(type: 'integer', nullable: false)]
    #[ORM\ManyToOne(targetEntity: JobItem::class)]
    #[ORM\JoinColumn(name: 'item', referencedColumnName: 'id', nullable: false)]
    protected ?GenericJobItem $item = null;

<etc>
#[ORM\Entity]
class JobItem extends GenericJobItem
{
}
use Doctrine\ORM\Mapping as ORM;

abstract class GenericJobItem
{
    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column]
    protected ?int $id = null;

<etc>

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

Originally created by @paullallier on GitHub (Dec 4, 2023). <!-- Before reporting a BC break, please consult the upgrading document to make sure it's not an expected change: https://github.com/doctrine/orm/blob/2.9.x/UPGRADE.md --> ### BC Break Report | Q | A |------------ | ------ | BC Break | yes | Version | Upgrading from 2.16.3 --> 2.17.0 (but still an issue in 2.17.1) #### 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:validate` reports no issues #### Current behavior `symfony console doctrine:schema:validate` reports many similar issues including: ``` [FAIL] The entity-class App\Entity\Organisation\Logo mapping is invalid: * The field 'App\Entity\Organisation\Logo#usage' has the property type 'string' that differs from the metadata field type 'int' returned by the 'integer' DBAL type. [FAIL] The entity-class App\Entity\Job\JobItemList mapping is invalid: * The field 'App\Entity\Job\JobItemList#item' has the property type 'App\Entity\Job\GenericJobItem' that differs from the metadata field type 'int' returned by the 'integer' DBAL type. ``` #### How to reproduce My Logo entity has a `usage` field that I'm storing as an integer and serving to / from the user as a string (essentially an enum handled with I normalise/denormalise). ``` use Doctrine\ORM\Mapping as ORM; #[ORM\Entity] class Logo { // Currently only one usage - but we might add more in future public const usages = ['document' => 1]; #[ORM\Id] #[ORM\GeneratedValue] #[ORM\Column] private ?int $id = null; #[ORM\Column(type: 'integer', nullable: false)] private ?string $usage = null; <etc> ``` The JobItemList should just be a ManyToOne mapping (made slightly more complex by having some of the properties in abstract cases): ``` use Doctrine\ORM\Mapping as ORM; #[ORM\Entity] class JobItemList extends GenericJobItemList { #[ORM\Id] #[ORM\Column] #[ORM\ManyToOne(targetEntity: JobItemListNumber::class)] #[ORM\JoinColumn(name: 'id', referencedColumnName: 'id', nullable: false)] protected ?int $id = null; #[ORM\Column(type: 'integer', nullable: false)] #[ORM\ManyToOne(targetEntity: JobItem::class)] #[ORM\JoinColumn(name: 'item', referencedColumnName: 'id', nullable: false)] protected ?GenericJobItem $item = null; <etc> ``` ``` #[ORM\Entity] class JobItem extends GenericJobItem { } ``` ``` use Doctrine\ORM\Mapping as ORM; abstract class GenericJobItem { #[ORM\Id] #[ORM\GeneratedValue] #[ORM\Column] protected ?int $id = null; <etc> ``` 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
admin closed this issue 2026-01-22 15:48:38 +01:00
Author
Owner

@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.

I'm only using ORM to keep keep my schema aligned with my API docs and not for DB persistence

🤨 what?

@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. > I'm only using ORM to keep keep my schema aligned with my API docs and not for DB persistence :raised_eyebrow: what?
Author
Owner

@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.

🤨 what?

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.

@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. > 🤨 what? 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.
Author
Owner

@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 ManyToOne relationship, I'm not sure this part is valid:

    #[ORM\Column(type: 'integer', nullable: false)]
    #[ORM\ManyToOne(targetEntity: JobItem::class)]
    #[ORM\JoinColumn(name: 'item', referencedColumnName: 'id', nullable: false)]
    protected ?GenericJobItem $item = null;

What does it mean to have $item mapped to a column with Column, and then to also have it mapped to a relationship with ManyToOne?

@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 `ManyToOne` relationship, I'm not sure this part is valid: ```php #[ORM\Column(type: 'integer', nullable: false)] #[ORM\ManyToOne(targetEntity: JobItem::class)] #[ORM\JoinColumn(name: 'item', referencedColumnName: 'id', nullable: false)] protected ?GenericJobItem $item = null; ``` What does it mean to have `$item` mapped to a column with `Column`, and then to also have it mapped to a relationship with `ManyToOne`?
Author
Owner

@paullallier commented on GitHub (Dec 4, 2023):

What does it mean to have $item mapped to a column with Column, and then to also have it mapped to a relationship with ManyToOne?

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!

        $this->addSql('ALTER TABLE job_item_list ADD CONSTRAINT FK_4B4853F21F1B251E FOREIGN KEY (item) REFERENCES job_item (id)');
        $this->addSql('CREATE INDEX IDX_4B4853F21F1B251E ON job_item_list (item)');
@paullallier commented on GitHub (Dec 4, 2023): > What does it mean to have `$item` mapped to a column with `Column`, and then to also have it mapped to a relationship with `ManyToOne`? 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! ``` $this->addSql('ALTER TABLE job_item_list ADD CONSTRAINT FK_4B4853F21F1B251E FOREIGN KEY (item) REFERENCES job_item (id)'); $this->addSql('CREATE INDEX IDX_4B4853F21F1B251E ON job_item_list (item)'); ```
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#7268