mirror of
https://github.com/doctrine/orm.git
synced 2026-03-23 22:42:18 +01:00
DDC-3480: ORM\Embeddable does not create ManyToOne column in the database #4286
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @doctrinebot on GitHub (Jan 9, 2015).
Jira issue originally created by user tvoslar:
Following Embeddable
won't save country attribute into the database table, other simple attributes (like type="text") saved normally.
@doctrinebot commented on GitHub (Jan 9, 2015):
@doctrinebot commented on GitHub (Jan 9, 2015):
Comment created by @ocramius:
The issue seems incomplete to me: what exactly is the failure? Can you make an example?
@doctrinebot commented on GitHub (Jan 9, 2015):
Comment created by tvoslar:
Okay, I am sorry. I have main entity which includes Embeddable entity (Address), this address entity contains country attribute with ManyToOne relation, but this country is not being saved into the database table, other attributes like street (string) are being saved normally.
@doctrinebot commented on GitHub (Jan 9, 2015):
Comment created by tvoslar:
Basically it creates main entity with all fields from embeddable except country which is ManyToOne.
@doctrinebot commented on GitHub (Jan 9, 2015):
Comment created by @ocramius:
Ah, now I get it (I was probably misreading it). We don't support associations from embeddables right now: please check the test suite, but they really don't provide this functionality right now.
@doctrinebot commented on GitHub (Jan 9, 2015):
Comment created by tvoslar:
And is there any chance it will be supported in the near future? Or it's not possible?
@doctrinebot commented on GitHub (Jan 9, 2015):
Comment created by @ocramius:
It will probably not implemented for now, as embeddables (in our vision) are fitting the use-case of ValueObjects. ValueObjects are (usually) supposed to be containing serializable data, and an entity reference is not serializable data.
@doctrinebot commented on GitHub (Jan 9, 2015):
Comment created by tvoslar:
Okay, understood. So it's not good idea to use embeddables for Address entity for example, with this country as relation to another table, right? It seemed to me like best case. Thank you for the support anyway.
@doctrinebot commented on GitHub (Jan 9, 2015):
Comment created by @ocramius:
I'd rather just save the country identifier in the embeddable instead.
@doctrinebot commented on GitHub (Jan 9, 2015):
Comment created by tvoslar:
So you mean, instead of ManyToOne, save just id=integer (so no relation with entity)?
@doctrinebot commented on GitHub (Jan 9, 2015):
Comment created by @ocramius:
Correct: simple scalar or serializable types
@doctrinebot commented on GitHub (Jan 9, 2015):
Comment created by tvoslar:
400acad533/tests/Doctrine/Tests/ORM/Functional/ValueObjectsTest.phpLine 121 method testDqlOnEmbeddedObjectsField, guess I am wrong, but it seems there should be support for embeddable with relations though.
@doctrinebot commented on GitHub (Jan 11, 2015):
Comment created by Yavin:
Hi,
if is is not supported i think an exception should be thrown when someone use association in embedded class. Now it is just silently ommited.
I found code where embedded metadata is added:
573153669c/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php (L3200)@doctrinebot commented on GitHub (Feb 2, 2015):
Comment created by eugene-d:
This should be explicitly stated in the documentation.
@doctrinebot commented on GitHub (Feb 2, 2015):
Comment created by @ocramius:
[~eugene-d] please send a PR to the documentation with the wording you prefer.
@doctrinebot commented on GitHub (Feb 9, 2015):
Comment created by eugene-d:
[~ocramius] http://www.doctrine-project.org/jira/browse/DDC-3556
@scaytrase commented on GitHub (Aug 3, 2016):
Any chance for embedded relations in 2016?
@Ocramius commented on GitHub (Aug 5, 2016):
@scaytrase no, the proper patch would be https://github.com/doctrine/doctrine2/pull/5809
@soullivaneuh commented on GitHub (Dec 13, 2016):
Breaking the relation by just replacing it with and integer is not terrible IMHO.
The case of the address embeddable class is very useful and most of the case, the country is a relation.
I understand the goal of value object, but if you are telling to save an ID, why not just tell the serializer to save the id of the relation?
In any case, the usage should be the concern of the developer IMHO.
@Ocramius Would you accept a PR integrating relation on embedded objects?
@Ocramius commented on GitHub (Dec 13, 2016):
@Soullivaneuh no, I've been clear on that. The correct patch is #5809, but it is incomplete.
@soullivaneuh commented on GitHub (Dec 13, 2016):
For now does not mean forever. 😛
Well, I guess I tried.
What would you suggest if we want to store the relation id onto the embeddable object like you said and still acquire the related object on entity load?
@Ocramius commented on GitHub (Dec 13, 2016):
@Soullivaneuh storing the identifier is an acceptable solution. Loading the related entity would then require looping back to the ORM.
@soullivaneuh commented on GitHub (Dec 13, 2016):
I'm sorry but I don't fully understand. Could you please elaborate a bit? What do you mean by looping back to the ORM? Maybe could you provide an example?
Thanks for your time.
@Ocramius commented on GitHub (Dec 14, 2016):
I mean by using
EntityManager#find()orEntityRepository#find()instead of relying on lazy loading.@jhonatanTeixeira commented on GitHub (Jun 12, 2017):
I guess it's retarded to not allow associations on embeddables just because for some it represents VO's.
If i want to use the VO concept on my project i simply won't use associations on my embeddables. However if i want to use embeddables for other purposes such as split of concerns and composition of objects to avoid inheritance (as good oop practice). Doctrine is suposed to be a flexible framework and not stand in the way i want to design my project because of some extremist view.
Every pattern depends on context and might not be the answer for every problem. The address and country is a clear case that the embeddables are not exclusively VO's.
And don't forget @Ocramius, doctrine is not exactly a DDD implementation, its an ORM and its perfectly fine if people wants to use it without the DDD concept.
@Ocramius commented on GitHub (Jun 12, 2017):
I'm very well aware that I'm retarded :-)
It is not, but every foot-gun we can avoid shipping is helpful.
Just design them as associations or entities: nothing wrong with that.
@Ocramius commented on GitHub (Jun 12, 2017):
Closing here meanwhile: if someone wants to take on the job of adding association mapping validation (preventing it, specifically) on metadata loading, feel free to do so.
@jhonatanTeixeira commented on GitHub (Jun 12, 2017):
Do you realize that adding more associations on a large project mey represent a big performance hit?
if i want to decompose my objects without affecting database performance on my projects i simply can't?
The hability to decompose objects while keeping a single table to avoid joins (and sometimes the responsability for hold some of the associations lies within those separeted objects) should not be restricted by the library. The correct use of VO's should be the developer's responsability.
And i'm sorry for the "retarded" word, it wasn't meant to offend you, it was to towards the idea in question and not you as a person. You are not retarded you are a very well respected professional and a really smart person.
@Ocramius commented on GitHub (Jun 12, 2017):
Considering hydration overhead and L2 cache support, this is very unlikely
a problem: since every embeddable converted to an association is also a
*-to-one on association, it is trivial to fetch-join those.
On 12 Jun 2017 18:11, "jhonatan" notifications@github.com wrote:
Do you realize that adding more associations on a large project mey
represent a big performance hit?
if i want to decompose my objects without affecting database performance on
my projects i simply can't?
The hability to decompose objects while keeping a single table to avoid
joins (and sometimes the responsability for hold some of the associations
lies within those separeted objects) should not be restricted by the
library. The correct use of VO's should be the developer's responsability.
And i'm sorry for the "retarded" word, it wasn't meant to offend you, it
was to towards the idea in question and not you as a person. You are not
retarded you are a very well respected professional and a really smart
person.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/doctrine/doctrine2/issues/4291#issuecomment-307819363,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJakFlZ229AzWa9-YMgl8h9Ou0MDmfKks5sDVULgaJpZM4JboYx
.
@Arkemlar commented on GitHub (Jun 29, 2017):
Since Embeddables is reserved to be VO. Why not create similar mechanism to allow required assotiations functionallity??
@Ocramius commented on GitHub (Jun 29, 2017):
That's what you call "entities" :-)
@Arkemlar commented on GitHub (Jun 29, 2017):
@Ocramius nope! Entities requires distinct table. But I mean just an object inside entity object, this object has relations with other entities. I need that decomposition because this nested object has special domain meaning and will be used-and-type hinted in some methods. Well, at this point it might be made as entity, but imagine if I need to do such decomposition many times for many entities - now I have to make one extra table and one more query for every usage. This not critical in my case but neither practical and optimal.
@ryall commented on GitHub (Jul 19, 2017):
@Ocramius I completely agree with @Arkemlar. Embeddables is a fantastic feature but it breaks the object flow having to save foreign keys directly instead of using an association. Also, VO Embeddables could just as easily be called "entities" - they provide no additional functionality over entities, just clean and logical grouping. Even if the performance hit for a join that you mentioned above is trivial, it breaks my code design and logical grouping having to move related associations outside of the Embeddable, and that for me somewhat defeats the point of having them in the first place.
@Arkemlar commented on GitHub (Jul 21, 2017):
@ryall Ocramius's point seems clear: he wont agree (at any case) with idea of making Embeddables to serve any other pattern/needs than VO. The question is: will @Ocramius agree if we (community) implement required functionality with other kind of objects (for example "EntityExtensions") - similar to Embeddables but with relations allowed?
@ryall commented on GitHub (Jul 21, 2017):
@Arkemlar Why would he agree to that if he won't allow it in Embeddables? His decision to disallow associations seems to be somewhat unpopular. There's also no good argument that I've heard about why this should be so.
Actually, it would be nicer and potentially solve this problem indirectly if Doctrine were made more modular and extensible which would allow us to then just replace the bits we want. Currently it's quite difficult and often impossible to extend it without editing the source directly. I hope 3.0 will be more than just a few shiny new features - Doctrine needs a complete refactor IMO.
@Ocramius commented on GitHub (Jul 21, 2017):
The ORM is not an extensible toolkit: throwing custom logic at the
internals is a recipe for quick and painfully hard to fix BC breaks. 3.x
focuses on feature removal, performance, consistency, internal
maintainability, reduction of defects coming from duplicate decision logic.
As for embedded values, for now associations in them are off limits. We
could rename the feature to "value objects" if the current intent isn't
clear enough.
The feature is completely gone in 3.x, and will be re-introduced once the
metadata refactoring is done.
On 21 Jul 2017 17:13, "Nat Ryall" notifications@github.com wrote:
@ryall commented on GitHub (Jul 21, 2017):
@Ocramius You still haven't really answered the question as to why they need to be value objects? Is it for compatibility reasons, a limitation of the system, or something else?
Maybe this is a little off topic but I'm happy to hear about the Metadata refactoring. I have no idea what you have planned but having one annotation per column type (ie
StringColumn,IntegerColumn) and making these extensible (instead of only basic types) would be a very nice improvement.@Ocramius commented on GitHub (Jul 21, 2017):
On 21 Jul 2017 18:29, "Nat Ryall" notifications@github.com wrote:
@Ocramius https://github.com/ocramius You still haven't really answered
the question as to why they need to be value objects? Is it for
compatibility reasons, a limitation of the system, or something else?
As mentioned in previous discussions, embedded values are multi-field
scalar types. They can especially be embedded because they are just values,
whereas new special rules would apply to associations (much like with
mapped superclasses). They were designed to add multi-field value object
mapping capabilities to the ORM, and not as php-style-traits to copy/paste
fields around.
Maybe this is a little off topic but I'm happy to hear about the Metadata
refactoring. I have no idea what you have planned but having one annotation
per column type (ie StringColumn, IntegerColumn) and making these
extensible (instead of only basic types) would be a very nice improvement.
Achieving what? You would likely just break loads of POPO logic. Also, you
can already implement this via metadata load event listeners, mich like
DoctrineExtensions does this.
@ryall commented on GitHub (Jul 24, 2017):
@Ocramius OK so if that's the case, if @Arkemlar's suggestion were to be implemented with a new type, such as
@Groupor@EntityExtension, would this be acceptable for a pull request? Owning-side associations would be easy enough to implement and there'd need to be some logic, and possibly additional association configuration, for non-owning-side associations.@Ocramius commented on GitHub (Jul 24, 2017):
@ryall unlikely: we are moving our focus to 3.x, where embeddables have been completely removed for now, and will need to be re-introduced/redesigned.
@guilhermeblanco commented on GitHub (Sep 2, 2017):
For the reference, since @lcobucci and I spoke about this issue.
Embeddables will be re-implemented, properly implemented. That should allow us to follow JPA 2.1, which states:
@soullivaneuh commented on GitHub (Nov 28, 2017):
@guilhermeblanco It's a great news! :-)
Do we already have commit about the concerned chance or is this not worked yet?
@fabwu commented on GitHub (May 16, 2018):
@guilhermeblanco Is there a corresponding PR for this feature or do you publish any progress in this issue?
@jaikdean commented on GitHub (May 25, 2018):
Doctrine 3 can't come soon enough!
@danaki commented on GitHub (Jul 2, 2020):
Still actual in 2020
@cedvan commented on GitHub (Oct 30, 2020):
up ?
@rkonopski commented on GitHub (Jan 30, 2021):
up?
@pcholewa commented on GitHub (Apr 26, 2021):
Still actual
@Gemorroj commented on GitHub (May 25, 2021):
up
@kirya-dev commented on GitHub (Jun 11, 2021):
six years.. good news. nothing changed!
@Ocramius commented on GitHub (Jun 11, 2021):
Reminder that this is intentional: embeddable types do not include
associations by design.
On Fri, Jun 11, 2021, 15:54 Kirill @.***> wrote:
@beberlei commented on GitHub (Jun 11, 2021):
We should throw an exception
@beberlei commented on GitHub (Jun 13, 2021):
Created #8763 for this to track progress for 3.0
@jhonatanTeixeira commented on GitHub (Jun 13, 2021):
I cant believe this, the comunity is asking for this for 6 years, meaning that the comunity disagree with your design, even other maintainers agreed with the idea years ago. A framework should be flexible for all use cases, not only for those implementing DDD
@beberlei commented on GitHub (Jun 13, 2021):
@jhonatanTeixeira The community gets this software for free. The software is shipped as is. This change is not easy to implement. Feel free to invest a few weeks of work into this, as I expect this will take. Locking this conversation now.
@Ocramius commented on GitHub (Jun 13, 2021):
Believe it then: software architecture is not a democratic process, and for
good reasons 😁
Embeddable types are designed for small, as-immutable-as-possible
value-encapsulating objects, not to build graphs.
On Sun, Jun 13, 2021, 15:12 Jhonatan Teixeira @.***>
wrote: