orm icon indicating copy to clipboard operation
orm copied to clipboard

[Docs] Nullable Embeddables Hydration section

Open iku12phycho opened this issue 1 year ago • 8 comments

Hi.

I faced to problem #4568. However, I could not find this issue quickly and I was confused...

The behavior should be documented in doctrine tutorial. It will be more kindness.

iku12phycho avatar Aug 27 '24 10:08 iku12phycho

Please kindly squash your commits together. If you don't, we'll try to remember to do it for you but it's best if you save us this trouble.

How to do that?

  1. git rebase -i origin/3.2.x, assuming origin is a git remote that points to this repository, and not your fork. If you're not sure what your remotes are, run git remote -vvv, there should be your fork and the holy/reference/base/origin/whatever-you-call-it repository.
  2. A window will show up with many lines, replace pick with fixup on every line but the first one
  3. Close your editor, git should do its magic, and you should end up with one commit
  4. Use git push --force to overwrite what you already push. Don't forget the --force option otherwise git will try to merge both things together.

greg0ire avatar Aug 28 '24 09:08 greg0ire

I'm trying to wrap my head around what's happening here. My understanding of embeddables is that we always hydrate them. Having this section elaborate on "nullable embeddables" feels weird because that concept does not exist in the ORM.

This section merely documents a weird workaround. I'm not sold that we should document that workaround, but if we do, we should first document the limitation that we attempt to work around before we document the actual workaround.

derrabus avatar Aug 28 '24 10:08 derrabus

Thanks you for your comment.

In case all fields in the embeddable are nullable, you might want to initialize the embeddable, to avoid getting a null value instead of the embedded object.

There is the above description in initializing embeddables section. If the step are not taken, "nullable embeddables" would effectively be possible.

We should document a difference between a instantiated entity object and a hydrated entity object.

iku12phycho avatar Aug 28 '24 11:08 iku12phycho

If the step are not taken, "nullable embeddables" would effectively be possible.

If you manually construct the object, of course any structure is possible. It's your object, you've created it, you've populated all properties and the ORM is not even aware of its existence. But the ORM will never hydrate null instead of an actual embeddable object if it builds the entity for you.

This btw applies the same way to any mapped property. For instance, a one-to-many association is hydrated as a collection. We could add a section about "nullable collections" because it's in theory possible to construct an object where the property that's supposed to hold the collection is null. But since that only creates an unnecessary edge case, we rather recommend to initialize collections in the constructor. And that's what we also do for embeddables.

We should document a difference between a instantiated entity object and a hydrated entity object.

If you find a nice way to do that, please go ahead.

derrabus avatar Aug 28 '24 11:08 derrabus

So, Is It like a bug that ORM accepts to flush a entity has a null value instead of the embedded object In Doctrine 3.2.x?

iku12phycho avatar Aug 29 '24 02:08 iku12phycho

So, Is It like a bug that ORM accepts to flush a entity has a null value instead of the embedded object In Doctrine 3.2.x?

I wouldn't call it that. The ORM tries to handle this situation gracefully instead of raising an exception. Do you think we should be more strict here?

derrabus avatar Aug 29 '24 06:08 derrabus

Sidenote: If this behavior isn't covered by tests yet, it would need one in case that the nullable embeddables concept will be officially supported and maintained.

SenseException avatar Aug 30 '24 22:08 SenseException

I wouldn't call it that. The ORM tries to handle this situation gracefully instead of raising an exception. Do you think we should be more strict here?

Yes. I feel odd that an object structure changes when to input into and output from the ORM. But, I can understand a property value changes according to RDB table scheme like an autoincremented id.

iku12phycho avatar Aug 31 '24 08:08 iku12phycho

There hasn't been any activity on this pull request in the past 90 days, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 7 days. If you want to continue working on it, please leave a comment.

github-actions[bot] avatar Nov 30 '24 03:11 github-actions[bot]

This pull request was closed due to inactivity.

github-actions[bot] avatar Dec 07 '24 03:12 github-actions[bot]