querying-over-self-references

[NOA-Alex]

Please use the form below, leaving the prefilled data to help us. Thank you.

Page link: querying-over-self-references

Document link: query-over.md

My Issue/Suggestion

If I compare this to https://academy.mendix.com/link/modules/373/lectures/3037/6.3.1-Querying-Players-(Children)-from-a-Buddy-(Parent) then I would name the association "SubFolder_Folder" or "SubFolder_ParentFolder". Unless I understood the concept wrong.

[MarkvanMents]

Hi Alex, Thanks for bringing this to our attention.

In the end, the naming of associations, and the direction you choose, is entirely up to you - as long as you are clear about what the association represents. I agree that the two examples are named the opposite way around In the academy course the query [SoccerSquad.Apprentice_Buddy = '[%CurrentObject%]'] returns all the Apprentices who are associated with a Buddy. I would therefore argue that it is more justified to call this relationship Buddy_Apprentice as, when queried this way around, it is defining the relationship between the Buddy and the Apprentice.

The convention used in the Querying Over Self-References document - is that when you use the query the right way around it returns all the SubFolders (the second part of the association) associated with the Folder (the first part of the association) and so the relationship is named Folder_SubFolder. When you used the reversed() expression it turns the association around and you match on the subfolder it is SubFolder->Folder.

I will discuss this with Academy and see whether we can agree on the naming here. It is obviously a complex area where it would be nice to have things as simple as possible.

I hope this helps to explain the difference. As always, you can rename associations in your apps to match the way you think about them.

Yours Mark van Ments.

[NOA-Alex]

Dear Mark,

No problem at all. I understand that most of it are recommendations and best practices and they can be changed/adapted based on the real use case and context, with the main goal to make it easier for another developer (or myself) to understand what that association is.

However, I found that it somehow makes sense for associations which are owned by one side to start with the name of the owning side. Also Mendix Studio Pro seems to make that by default. If I would have 2 separate entities apprentice and buddy or sub-folder and folder and would connect from the many to the 1 then Mendix Studio Pro would name the entities automatically Apprentice_Buddy and SubFolder_Folder. That is the main reason why I would apply the same naming patterns also for the self-reference if folder and sub-folder are the same entity.

Nevermind, I am preparing for the Advanced Developer Certificate and thought if you guys spent so much time preparing so good documentation and courses then if I see something which might need your review then I will shortly point it out.

So all good here :-)

Cheers,

Photo https://www.linkedin.com/in/lechalexandermurawski Alex Murawski CEO & Founder +86 186 1710 1085 <tel:+86 186 1710 1085> @.*** Reviews https://g.page/noa-labs-ltd?gm

www.noa-labs.com https://www.noa-labs.com/

On 2023-05-30 22:56, Mark van Ments wrote:

Hi Alex, Thanks for bringing this to our attention.

In the end, the naming of associations, and the direction you choose, is entirely up to you - as long as you are clear about what the association represents. I agree that the two examples are named the opposite way around In the academy course the query |[SoccerSquad.Apprentice_Buddy = '[%CurrentObject%]']| returns all the |Apprentices| who are associated with a |Buddy|. I would therefore argue that it is more justified to call this relationship |Buddy_Apprentice| as, when queried this way around, it is defining the relationship between the |Buddy| and the |Apprentice|.

The convention used in the Querying Over Self-References https://docs.mendix.com/refguide/query-over/ document - is that when you use the query the right way around it returns all the |SubFolders| (the second part of the association) associated with the |Folder| (the first part of the association) and so the relationship is named |Folder_SubFolder|. When you used the |reversed()| expression it turns the association around and you match on the subfolder it is |SubFolder|->|Folder|.

I will discuss this with Academy and see whether we can agree on the naming here. It is obviously a complex area where it would be nice to have things as simple as possible.

I hope this helps to explain the difference. As always, you can rename associations in your apps to match the way you think about them.

Yours Mark van Ments.

— Reply to this email directly, view it on GitHub https://github.com/mendix/docs/issues/6102#issuecomment-1568586929, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFEHME4GYOUROMKLK4XVHB3XIYDA7ANCNFSM6AAAAAAYSWVCGY. You are receiving this because you authored the thread.Message ID: @.***>

[MarkvanMents]

Thanks for your detailed response, Alex. I now understand a bit more where the naming is coming from and, I agree, the default naming would be better to follow in the documentation. I wasn't aware that the "child/owner" is the default to have first in Mendix naming - it is something I should have been aware of.

I'll reopen this issue and look at the document and let you know when I've made the changes.

Thanks again for taking the time to explain the issue and point out the confusion in the documentation.

[NOA-Alex]

Dear Mark,

You are very welcome. And just to clarify it: in the screenshot or example I mentioned in my last email I just used drag-and-drop from the one entity to the other entity. Which creates automatically a *-1 association from the first to the second entity. And automatically a name with the FirstName_SecondName.

Which in most cases actually makes even sense. Though I fully agree with you that in certain cases the developer should adjust those automatically generated association names where it helps to make the meaning of that association easier or more clear to understand.

In any case: Good luck updating and creating new content! As it helps new and old Mendix developers a lot to learn general and Mendix specific topics to accelerate building no-code/low-code Apps :-)

Regards,

Photo https://www.linkedin.com/in/lechalexandermurawski Alex Murawski CEO & Founder +86 186 1710 1085 <tel:+86 186 1710 1085> @.*** Reviews https://g.page/noa-labs-ltd?gm

www.noa-labs.com https://www.noa-labs.com/

On 2023-05-31 15:01, Mark van Ments wrote:

Thanks for your detailed response, Alex. I now understand a bit more where the naming is coming from and, I agree, the default naming would be better to follow in the documentation. I wasn't aware that the "child/owner" is the default to have first in Mendix naming - it is something I should have been aware of.

I'll reopen this issue and look at the document and let you know when I've made the changes.

Thanks again for taking the time to explain the issue and point out the confusion in the documentation.

— Reply to this email directly, view it on GitHub https://github.com/mendix/docs/issues/6102#issuecomment-1569605353, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFEHME27UZB7NNGCIMRUUULXI3UDNANCNFSM6AAAAAAYSWVCGY. You are receiving this because you authored the thread.Message ID: @.***>

[MarkvanMents]

Hi @NOA-Alex I've updated the text and diagrams in pull request #6172 . I'll merge it now and it should be published later today. Thanks again for pointing out this mistake and taking the time to explain it. Please do let us know if you spot anything else which is wrong or could be improved. Yours Mark van Ments.

[MarkvanMents]

Issue addressed.

[NOA-Alex]

Dear @MarkvanMents, You are the best! Thanks for maintaining and updating the very good Mendix documentation. Which makes it easier for developers to build useful and beautiful web and smartphone apps. Regards, Alex