defining indexes in Table attribute doesn't work, I have to use Index attribute instead

Question

this way of defining indexes seem not to be working

#[ORM\Table(
    name: 'custom_article_table_name',
    indexes: [
        new ORM\Index(name: 'name_index', columns: ['name'])
    ]
)]

I had to convert it to

#[ORM\Table(name: 'custom_invoice_table_name')]
#[ORM\Index(name: 'date_index', columns: ['date'])]

bug documentation to reproduce
https://gitlab.com/idlab-public/doctrine-attribute-index-bug

I don't know if this is a bug in Doctrine or the implementation of indexes:... is not fully supported in attributes arguments ?

All I have found is people fixing it with #[ORM\Index] attributes

related articles

https://stackoverflow.com/questions/73038623/why-doctrine-migrations-ignore-my-index-declaration

https://stackoverflow.com/questions/72744338/doctrine-migration-created-by-symfonymakerbundle-tries-to-remove-existing-indexe

Comments

What PHP version are you using? I believe this can be caused by bug/missing feature in Php 8, but already fixed in 8.1

---

I'm using PHP 8.1.0

---

This is strange, other users already confirmed that this format of definition worked for them correctly on Php 8.1+

Can you please double-check the version?

The issue is that the format you're mentioning as working is different than the Annotation format. Currently export shares the same base logic for annotations and attributes and we can't simply switch it to the #[ORM\Index] format without breaking annotations.

---

Hello Ludek,

We have checked on several configurations, (mac OS, Debian and Windows) with PHP 8.1, Symfony 5.4 (LTS) and Doctrine ORM 2.13.1. We all have the same issue.

I was planing to report the bug to the Doctring ORM team, but as I was browsing their open issues, I understood they are moving away from nested attributes (which are supported since PHP 8.1) towards split attributes.
source: https://github.com/doctrine/orm/issues/9540#issuecomment-1048026426

Attributes documented here do not mention the nested Table#indexes attribute anymore
https://www.doctrine-project.org/projects/doctrine-orm/en/2.11/reference/attributes-reference.html#attributes-reference

I added a workaround by rolling back to annotation in my bug sample repo:
https://gitlab.com/idlab-public/doctrine-attribute-index-bug

Best regards

---

Hi,

thanks for keeping me udpate. In this case, we need to update it in the export system when they decided to move away from nested attributes.

We will check how to do that.

But I consider their decision very bad. This introduces two different definition formats for the single thing.

---

I think baberlei agrees on the principle of not having both systems live together, he says:

we discussed allowing both ways in #9240 and decided against because
of the complexity and confusion of two ways. I'd rather instead throw
an exception if Table#uniqueConstraints isset

I have no idea if this is a decision or a wish he makes …? Maybe get in touch with him :-)

Thank you for maintaining your great software with so much care ;-)

---

I read that, but I believe this only means "both ways" for attributes, not "for attributes and annotations".

The "problem" is that till now we had the same "meta-export" which then convert the format to annotations or attributes. But now we have to include several "if-defs" to the export only because there are differences between anns and attrs.

But we have to reconcile with the fact that everything is not always perfect ;-).

Anyway, we're already working on that. As far as I know, we have to implement it for JoinColumn, InverseCoinColumn, JoinTable, Index, UniqueIndex.

I will let you know when the update will be ready.

Answer 1

Hello,

new Skiper version with updated Attributes export for JoinColumn, InverseJoinColumn, JoinTable, Index, UniqueIndex is available for download.

Please test it and let me know if it solves all issues you had.

https://www.skipper18.com/support/402/downloads-skipper-beta

We had to implement several if-def sections and refact some import/export but based on our unit testing everything is working smoothly.