Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BUGFIX: Do not join select property paths to embedded objects #1404

Merged
merged 3 commits into from
Aug 26, 2019

Conversation

vertexvaar
Copy link
Contributor

@vertexvaar vertexvaar commented Oct 9, 2018

Instead of assuming that every property path with a dot is a path
to an other entity check if the property path is a mapped field which
is also true for embedded object properties.

Resolves #989

What I did
We'll i suppose i fixed it 😅

How I did it
I searched the existing class schema for hints about embedded properties and found it in the entityManager. When the path exists in the fieldMappings it is a field embedded in the object's table. Since we're using doctrine in this kind of query anyway i think we're safe to go whit this solution.

How to verify it
The description of the original bug should be suffice.

Checklist

  • Code follows the PSR-2 coding style
  • Tests have been created, run and adjusted as needed
  • The PR is created against the lowest maintained branch

Instead of assuming that every property path with a dot is a path
to an other entity check if the property path is a mapped field which
is also true for embedded object properties.

Resolves neos#989
@albe
Copy link
Member

albe commented Oct 10, 2018

Woah, that looks too nice to be true :D Thanks for digging into this!

A few things:

  • what are the performance implications with the classMetadata lookup for every property?
  • doesn't the check also need to happen in the lower path of the code, when walking through a longer path?
  • please let's try to provide a test that shows the buggy behaviour and verifies the fix. I can help if needed

@vertexvaar
Copy link
Contributor Author

When i wrote the fix i had the following (and misquoted btw 😅 ) saying in mind:

For every complex problem there is an answer that is clear, simple, and wrong

But that one seems to to do the job. Well, we should test that extensively before merging, but i can't invest time in test at this point so i'm counting on you guys 😉

what are the performance implications with the classMetadata lookup for every property

The classMetaData is already fully built (and hold available throughout the request) and the hasField is just an isset

doesn't the check also need to happen in the lower path of the code, when walking through a longer path?

i haven't checked that yet but as it seems any path (e.g. if you embedd an embeddable in an embeddable in your object) is existent in the mappedFields array.

please let's try to provide a test that shows the buggy behaviour and verifies the fix. I can help if needed

Yes, tests are required and especially tests that check that no other unwanted side effects will pop up. Your help is very appreciated here ☺️

@albe
Copy link
Member

albe commented Nov 15, 2018

Sorry, I totally lost track of this one. Currently a bit too loaded to get into it unfortunately :( Would like to hear @kdambekalns - should we maybe merge this even without a test in place?

@kdambekalns
Copy link
Member

TBH I'd rather have a test…

@bwaidelich
Copy link
Member

I'm with @kdambekalns - this is too critical not to be tested (but unfortunately I currently lack the resources and insight to add those, sorry)

@albe albe self-assigned this Apr 20, 2019
@albe
Copy link
Member

albe commented Apr 20, 2019

Assigning to myself for now to hopefully find a bit of time to add a test and get this in sometime soon.

@bwaidelich bwaidelich removed their request for review May 20, 2019 10:11
@albe
Copy link
Member

albe commented Aug 23, 2019

Finally found the inspiration and will to do it. I'm so sorry it took so absurdly long for this pretty trivial test...

Edit: and it's so late, that I make the stupidest mistakes in this trivial test, like having a limit(1) and expecting 2 results... 🤦‍♂

@albe
Copy link
Member

albe commented Aug 23, 2019

Green 🎉
@bwaidelich @kdambekalns I'd merge this on monday if none of you object

@albe
Copy link
Member

albe commented Aug 24, 2019

/rebase

Hm, apparently the github action only works if the branch targeted already contains the action workflow I guess :/

Copy link
Member

@kdambekalns kdambekalns left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good…

@albe albe merged commit 4f18b90 into neos:4.3 Aug 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants