Immutable Entities #5353

Closed
opened 2026-01-22 15:05:13 +01:00 by admin · 12 comments
Owner

Originally created by @davidbarratt on GitHub (Dec 20, 2016).

Originally assigned to: @lcobucci on GitHub.

Is there a way to have immutable entities? My problem is that for instance if you create an entity and then persist it, Doctrine wants to set the id of the object.

Is there a way to have the persist method return a new object with the id on it?

Originally created by @davidbarratt on GitHub (Dec 20, 2016). Originally assigned to: @lcobucci on GitHub. Is there a way to have immutable entities? My problem is that for instance if you create an entity and then persist it, Doctrine wants to set the id of the object. Is there a way to have the persist method return a new object with the id on it?
admin added the Invalid label 2026-01-22 15:05:13 +01:00
admin closed this issue 2026-01-22 15:05:13 +01:00
Author
Owner

@lcobucci commented on GitHub (Dec 20, 2016):

@davidbarratt if you want that you should not use a generated ID.

Maybe using an UUID would be better for you, you set it upfront (e.g. constructor) and the ORM would only use that value.

@lcobucci commented on GitHub (Dec 20, 2016): @davidbarratt if you want that you should not use a generated ID. Maybe using an UUID would be better for you, you set it upfront (e.g. constructor) and the ORM would only use that value.
Author
Owner

@davidbarratt commented on GitHub (Dec 20, 2016):

@lcobucci well that's an interesting solution I hadn't considered. I suppose objects loaded from the database just overload the properties on creation? Or do they need setters?

@davidbarratt commented on GitHub (Dec 20, 2016): @lcobucci well that's an interesting solution I hadn't considered. I suppose objects loaded from the database just overload the properties on creation? Or do they need setters?
Author
Owner

@JCMais commented on GitHub (Dec 20, 2016):

@davidbarratt reflection is used, no need for setters: cd1a5fcadc/lib/Doctrine/ORM/UnitOfWork.php (L2578)

@JCMais commented on GitHub (Dec 20, 2016): @davidbarratt reflection is used, no need for setters: https://github.com/doctrine/doctrine2/blob/cd1a5fcadce6cd5fe3ee17360503d73e82852339/lib/Doctrine/ORM/UnitOfWork.php#L2578
Author
Owner

@davidbarratt commented on GitHub (Dec 20, 2016):

@JCMais ok great! so the only feature that is really missing, is being able to use auto generated ids, but it's good to know there is a workaround.

@davidbarratt commented on GitHub (Dec 20, 2016): @JCMais ok great! so the only feature that is really missing, is being able to use auto generated ids, but it's good to know there is a workaround.
Author
Owner

@davidbarratt commented on GitHub (Dec 20, 2016):

Or rather... I should say that you cannot use immutable entities with @GeneratedValue() since that would mutate your object, correct?

@davidbarratt commented on GitHub (Dec 20, 2016): Or rather... I should say that you cannot use immutable entities with `@GeneratedValue()` since that would mutate your object, correct?
Author
Owner

@lcobucci commented on GitHub (Dec 20, 2016):

Or rather... I should say that you cannot use immutable entities with @GeneratedValue() since that would mutate your object, correct?

Indeed, generated identifiers are also configured via reflection but in the end it would change the state of the object after it's creation (which removes the whole immutable idea).

@lcobucci commented on GitHub (Dec 20, 2016): > Or rather... I should say that you cannot use immutable entities with @GeneratedValue() since that would mutate your object, correct? Indeed, generated identifiers are also configured via reflection but in the end it would change the state of the object after it's creation (which removes the whole immutable idea).
Author
Owner

@lcobucci commented on GitHub (Dec 20, 2016):

With that said we'll close this as invalid (since there's nothing to be done on the ORM) 😉

@lcobucci commented on GitHub (Dec 20, 2016): With that said we'll close this as `invalid` (since there's nothing to be done on the ORM) 😉
Author
Owner

@davidbarratt commented on GitHub (Dec 20, 2016):

@lcobucci I guess the only way around that would be for Doctrine to generate / return a new object? Can I open a feature request for an option to force Doctrine to do this?

@davidbarratt commented on GitHub (Dec 20, 2016): @lcobucci I guess the only way around that would be for Doctrine to generate / return a new object? Can I open a feature request for an option to force Doctrine to do this?
Author
Owner

@lcobucci commented on GitHub (Dec 20, 2016):

@davidbarratt the ORM is not responsible for creating a new object, it just gets an object that the user created and persists it (following the provided mapping).

You can definitely open the feature request but I don't think it would be implemented/accepted. The idea couples your domain to a detail (persistence), which is not something good when talking about object oriented design and architecture.
It would also push some extra complexity to the ORM, which is something that we always try to avoid 😃.

@lcobucci commented on GitHub (Dec 20, 2016): @davidbarratt the ORM is not responsible for creating a new object, it just gets an object that the user created and persists it (following the provided mapping). You can definitely open the feature request but I don't think it would be implemented/accepted. The idea couples your domain to a detail (persistence), which is not something good when talking about object oriented design and architecture. It would also push some extra complexity to the ORM, which is something that we always try to avoid 😃.
Author
Owner

@davidbarratt commented on GitHub (Dec 20, 2016):

@lcobucci which is worse, the coupling (domain to a detail), or mutable data in OOP?

@davidbarratt commented on GitHub (Dec 20, 2016): @lcobucci which is worse, the coupling (domain to a detail), or mutable data in OOP?
Author
Owner

@lcobucci commented on GitHub (Dec 20, 2016):

@davidbarratt IMHO coupling (specially when talking about your domain). Mutability creates complexity which is not necessarily a problem.

@lcobucci commented on GitHub (Dec 20, 2016): @davidbarratt IMHO coupling (specially when talking about your domain). Mutability creates complexity which is not necessarily a problem.
Author
Owner

@Ocramius commented on GitHub (Dec 23, 2016):

Actually very simple to implement: use @Entity(readOnly=true) :-)

The rest (API-wise) is up to you, sorry.

@Ocramius commented on GitHub (Dec 23, 2016): Actually very simple to implement: use `@Entity(readOnly=true)` :-) The rest (API-wise) is up to you, sorry.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#5353