You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are some discussions exists about this subject on github. Learned that doctrine manages the nullable embeddable objects different than I think. Seems like having a literally empty instance for both nullable and non-nullable cases is preferred in ORM land. This comment from the discussions below nicely summaries the situation:
by setting nullable as TRUE you are making it nullable: you are not accepting the idea of invalid data being hydrated. "nullable" and "inconsistent" are very different concepts, and SQL DBMSs without struct-like fields aren't able to deal with this sort of data-integrity problem in a decent way, therefore it's simply better to avoid the problem in first place by putting a strict limitation instead of building more foot-gunning tools - ocramius
doctrine2 4568 - Embeddable hydrates to object instead of null
Some facts that I found and understand so far:
Wishing a nullable value object to utilize in our entities doesn't means that we cannot have partial (incomplete) VO objects on runtime. Preventing a possible write operation to the database with an incomplete value object seems like responsibility of the developer.
Nullable value objects may have a method to tell outside if the instance is empty (all fields are null) or not. I'll create another PR for this.(This was a really bad idea. I'll revert it soon. Having an isEmpty() method in instance is not way to go) Anyway, still an empty value object instance is NOT EQUALS to null.
Object hydration must (or should) be done outside the ORM. With or without an ORM, application should know how to hydrate domain entities from various input formats and sources (serialized, json, native array, xml..).
When utilizing embeddables, seems like having an empty value object instead of managing nulls is more straightforward. Official documentation is also recommends this here.
Since all attributes of the value objects in this library marked as nullable, I'm planning to create a PR to allow empty object construction by changing all constructors from
publicfunction__construct($hex) { } : Color
to
publicfunction__construct($hex = null) { } : Color
I would like to hear opinions from others on this subject. Please feel free to share your thoughts.
The text was updated successfully, but these errors were encountered:
* Improve Goepoint, add more and proper tests
* Allow empty state for all value objects #11#12
* Fixing some grammar @yasinaydin
* update for contributing message (#13) @hkulekci
There are some discussions exists about this subject on github. Learned that doctrine manages the nullable embeddable objects different than I think. Seems like having a literally empty instance for both nullable and non-nullable cases is preferred in ORM land. This comment from the discussions below nicely summaries the situation:
Some facts that I found and understand so far:
I'll create another PR for this.(This was a really bad idea. I'll revert it soon. Having an isEmpty() method in instance is not way to go) Anyway, still anempty value object
instance is NOT EQUALS tonull
.nulls
is more straightforward. Official documentation is also recommends this here.Since all attributes of the value objects in this library marked as
nullable
, I'm planning to create a PR to allow empty object construction by changing all constructors fromto
I would like to hear opinions from others on this subject. Please feel free to share your thoughts.
The text was updated successfully, but these errors were encountered: