Hi, I wanted to drill a bit more onto Marco's statement in https://github.com/doctrine/doctrine2/issues/4568#issuecomment-245402433,
> implementing embeddables as hidden one-to-one records The "Flow" Framework did this from the beginning with its implementations of "Value Objects" and serious challenging problems arised. It worked/works the following way: - A value object is a (unique) record in a database table - The ID of that value object is, unlike usual entities, a *checksum* of the properties of the value object - Flow used to calculate the checksum on incoming ctor arguments which was wrong, but meanwhile (by @AkiiZedd, just saying) The experience with Flow's implentation showed the following: - The checksum must at least be built from the properties _after_ constructor invocation, i.e. on actual persisting/flush, because ctor can modify the arguments - I guess the intention of doing it the Flow way, hashing the incoming ctor args, was to be able to find a probably existing VO just from given arguments, e.g. on form submission - A social aspect: because being used of it, I've seen people striving to bugger about the VO's "identity" and giving around and working with the identitiy because it's "so much simpler" to just pass this one around. As you can imagine this introduced new problems. - I personally very preferred the way Doctrine actually did this already, with additional fields on the owning entity, because this emphasized what VOs are: a bunch of attributes, nothing more. So, I'm gladly open for discussion in this topic, surely also @AkiiZedd will be on board as I could imagine. Have a nice week, best, Adrian -- You received this message because you are subscribed to the Google Groups "doctrine-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/doctrine-user. For more options, visit https://groups.google.com/d/optout.
