Avoid StackoverflowError when updating entity

[OmarHawk]

when elasticsearch is enabled. We do add Spring Data
Transient annotation on the non-owning side
of relationships to break the artificial cycle introduced with the
bidirectional relationship model

Fix #18729
Fix #14840
Fix #16136

---

Please make sure the below checklist is followed for Pull Requests.

• All continuous integration tests are green
• Tests are added where necessary
• The JDL part is updated if necessary
• jhipster-online is updated if necessary
• Documentation is added/updated where necessary
• Coding Rules & Commit Guidelines as per our CONTRIBUTING.md document are followed

When you are still working on the PR, consider converting it to Draft (below reviewers) and adding skip-ci label, you can still see CI build result at your branch.

[ko5tik]

You should consider adding unit tests for this feature or extend existing with assertions about generated annotations
( under directory test/* )

[OmarHawk]

You should consider adding unit tests for this feature or extend existing with assertions about generated annotations ( under directory test/* )

True, ideally, there would be tests that check the actual functionality and not just the presence of some annotations. I'll see, what I can do easily.

[OmarHawk]

Meh, due to the changes of #17488 entities with custom id names will fail compilation 👎

Will fix this at well.

[OmarHawk]

Ok, so whenever I put a required validation attribute to an entity's relationship, tests do get generated that perform also the previously failing things (I tested manually for now with my jdl that produced failing PUT methods).
This is already there, so I'd just extend some sample jdls with this attribute and then we are supposed to see things working or not working :-)

[ko5tik]

You should consider adding unit tests for this feature or extend existing with assertions about generated annotations ( under directory test/* )

True, ideally, there would be tests that check the actual functionality and not just the presence of some annotations. I'll see, what I can do easily.

I mean unit tests for generator itself. And maybe also for CI

[OmarHawk]

I mean unit tests for generator itself. And maybe also for CI

Well, during the CI here, plenty of applications are produced and their automated tests are being run, so adding this case into the sample applications' datamodel to reproduce the case should be sufficient.

[DanielFran]

Thanks @OmarHawk for the contribution.
Do not forget to claim the bug bounty in #14840

[OmarHawk]

Thanks @OmarHawk for the contribution. Do not forget to claim the bug bounty in #14840

Thanks. :)
Claiming via https://opencollective.com/generator-jhipster/expenses/82218

[DanielFran]

@OmarHawk approved

[mheidt]

Are you guys certain, that @transient is the solution?
Yes, it prevents the stack overflow. But the index is empty as well.
This is the issue:
You have a relationship chain from A->B->A
I want either A->B in my elastic index as well as B->A
A solution with transient breaks either one of them.
And a Mapstruct solution doesn't work as the generated setters are rewiring it again.

[OmarHawk]

Well, at least it avoids that the functionality is not available at all. And what we currently do is generating the transient annotation only in one direction of the relationship if I remember my thoughts about that again, so that the index is not really empty.

What this Pull Request also does not do is checking whether someone actually created a cycle in it's data model... this would also requiring to break the cycle somehow...

[mheidt]

Yes, and in most cases this solves the case, because you don't need both directions.
The rewiring of the parent relation rather bothers me.
At least there should be an additional setter that is not doing it, so that I can try to make mapstruct use that one.