Use query expression in indexBy. #6145

New Issue

admin · 2026-01-22T15:27:37+01:00

admin commented

2026-01-22 15:27:37 +01:00

Originally created by @I70l0teN4ik on GitHub (Dec 20, 2018).

Originally assigned to: @Ocramius on GitHub.

Feature Request

Q	A
New Feature	yes
RFC	no
BC Break	no

Summary

Would be very useful to pass query expression to indexBy. Especially if you have a relation to entities with a composite primary key.
Let's say we have an entity Foo with a collection of Bar. But Bar actually has a unique and potentially a primary key on: foo_id + baz_id + quux_id. So simply passing the concat expression would give a guaranteed unique index for collection inside one Foo.
This would help to avoid issues in unit of work during the update of Foo.

@ORM\OneToMany(targetEntity="Bar", mappedBy="foo", indexBy="CONCAT(baz_id, quux_id)")

Originally created by @I70l0teN4ik on GitHub (Dec 20, 2018). Originally assigned to: @Ocramius on GitHub. ### Feature Request  | Q | A |------------ | ------ | New Feature | yes | RFC | no | BC Break | no #### Summary Would be very useful to pass query expression to indexBy. Especially if you have a relation to entities with a composite primary key. Let's say we have an entity Foo with a collection of Bar. But Bar actually has a unique and potentially a primary key on: foo_id + baz_id + quux_id. So simply passing the concat expression would give a guaranteed unique index for collection inside one Foo. This would help to avoid issues in unit of work during the update of Foo. @ORM\OneToMany(targetEntity="Bar", mappedBy="foo", indexBy="CONCAT(baz_id, quux_id)")

admin added the New Feature Won't Fix Question labels 2026-01-22 15:27:37 +01:00

admin closed this issue

2026-01-22 15:27:37 +01:00

admin commented

2026-01-22 15:27:38 +01:00

@Ocramius commented on GitHub (Dec 21, 2018):

Closing as won't fix: same reasoning as https://github.com/doctrine/doctrine2/issues/7535#issuecomment-449188277

What could be done (in my opinion) is implementing surrogate read-only entity fields that are only hydrated, and never considered by the UnitOfWork. Once that's done, this becomes a trivial operation.

@Ocramius commented on GitHub (Dec 21, 2018): Closing as `won't fix`: same reasoning as https://github.com/doctrine/doctrine2/issues/7535#issuecomment-449188277 What could be done (in my opinion) is implementing surrogate read-only entity fields that are only hydrated, and never considered by the `UnitOfWork`. Once that's done, this becomes a trivial operation.

admin referenced this issue

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

[PR #6145] Improving the documentation of enums as discriminators test #9870

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#6145