DDC-3937: Better GeneratedValue #4815

New Issue

admin · 2026-01-22T14:49:52+01:00

admin commented

2026-01-22 14:49:52 +01:00

Originally created by @doctrinebot on GitHub (Oct 5, 2015).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user maryo:

The ability to write custom ID generator is cool. However it is usable for primary key only. It would be very nice if it was possible to define GeneratedValue (or something simmilar) on any field. It would be then fetched and set after insertion. It would be useful for sequences, triggers, defaultValue (which accepts any DDL) etc. And since metadatas are not easily extendable, the only way to achieve something simmilar is quite a lot of code.

Originally created by @doctrinebot on GitHub (Oct 5, 2015). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user maryo: The ability to write custom ID generator is cool. However it is usable for primary key only. It would be very nice if it was possible to define GeneratedValue (or something simmilar) on any field. It would be then fetched and set after insertion. It would be useful for sequences, triggers, defaultValue (which accepts any DDL) etc. And since metadatas are not easily extendable, the only way to achieve something simmilar is quite a lot of code.

admin added the New Feature label 2026-01-22 14:49:52 +01:00

admin commented

2026-01-22 14:49:53 +01:00

@kasparsklavins commented on GitHub (Mar 15, 2017):

I could try try implementing this if there is support for it.

As a result, mysql CURRENT_TIMESTAMP, virtual columns and trigger-setted values will be supported.

Read only properties were rejected before (see https://github.com/doctrine/doctrine2/pull/1052 ), but that pull request was more about code generation and not about taking advantage of database features.

@kasparsklavins commented on GitHub (Mar 15, 2017): I could try try implementing this if there is support for it. As a result, mysql `CURRENT_TIMESTAMP`, virtual columns and trigger-setted values will be supported. Read only properties were rejected before (see https://github.com/doctrine/doctrine2/pull/1052 ), but that pull request was more about code generation and not about taking advantage of database features.

admin commented

2026-01-22 14:49:53 +01:00

@Ocramius commented on GitHub (Mar 15, 2017):

Supporting custom ID would need querying for the value right after it is inserted, and that doesn't really seem feasible, nor will work with bulk inserts anyway...

Fine by me if you want to try, but if it ends up butchering performance for this edge case, it's usually not worth exploring.

@Ocramius commented on GitHub (Mar 15, 2017): Supporting custom ID would need querying for the value right after it is inserted, and that doesn't really seem feasible, nor will work with bulk inserts anyway... Fine by me if you want to try, but if it ends up butchering performance for this edge case, it's usually not worth exploring.

admin commented

2026-01-22 14:49:54 +01:00

@maryo commented on GitHub (Nov 16, 2018):

@Ocramius I don't understand what you mean, custom IDs are already supported for a long time. So the mentioned problem is already solved if i undertand it correctly. What I wanted was to support it even for other properties. I prefer entities with UUIDs generated on the "client" which are always valid even before inserted to the database. But database interaction is sometimes needed unfortunately.

https://github.com/doctrine/doctrine2/blob/2.7/lib/Doctrine/ORM/UnitOfWork.php#L940

So here, instead of always calling setIdentifierValues it would allow to set different properties (mostly the annotated property). And OFC there are few other places.

For example you could have a UUID primary key but still use a sequence on a non-id property (or one could use a value generated by a trigger).

There are other ways how to achieve this like obtaining the value explicitly from the outside and passing it to it's constructor, passing a callback which obtains it from the inside, using a listener etc). But only this way it can be an atomic operation done very easily.

@maryo commented on GitHub (Nov 16, 2018): @Ocramius I don't understand what you mean, custom IDs are already supported for a long time. So the mentioned problem is already solved if i undertand it correctly. What I wanted was to support it even for other properties. I prefer entities with UUIDs generated on the "client" which are always valid even before inserted to the database. But database interaction is sometimes needed unfortunately. https://github.com/doctrine/doctrine2/blob/2.7/lib/Doctrine/ORM/UnitOfWork.php#L940 So here, instead of always calling setIdentifierValues it would allow to set different properties (mostly the annotated property). And OFC there are few other places. For example you could have a UUID primary key but still use a sequence on a non-id property (or one could use a value generated by a trigger). There are other ways how to achieve this like obtaining the value explicitly from the outside and passing it to it's constructor, passing a callback which obtains it from the inside, using a listener etc). But only this way it can be an atomic operation done very easily.

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#4815