Closed yelhouti closed 4 years ago
I'll test this out and fix it. Thanks for reporting this issue!
I wonder if it's not an issue with the generator, that should allow unidirectional many to many...
The fix is quite easy:
the code to add in the entity parser, after l.350
if (!relatedRelationship.injectedFieldInTo) {
relationship.otherEntityRelationshipName = lowerFirst(relatedRelationship.from);
const otherSideRelationship = {
relationshipName: camelCase(relatedRelationship.from),
otherEntityName: camelCase(relatedRelationship.from),
relationshipType: _.kebabCase(MANY_TO_MANY),
otherEntityField: lowerFirst(otherSplitField.otherEntityField),
otherEntityRelationshipName: lowerFirst(relatedRelationship.to),
ownerSide: false
};
relatedRelationship.type = MANY_TO_MANY;
entities[relatedRelationship.to].addRelationship(otherSideRelationship);
}
@MathieuAA This is what I tried to explain in the issue, sadly didn't have time to work on it, I'm in a bit of pickle these days with some projects so sorry, I can't help any further for now.
Don't worry! I'll try to get to the bottom of this :) again, thanks for reporting this one
Overview of the issue
The "non Owner" side of ManyToMany relationship is not always present in JDL, (making fluent methods in the generator break)
If this is a "feature" not a bug, how can the generator know that
Set<A>
will not be present inB.java
to avoid callingb.getAS().add(this);
inA.java
If we want to keep this behavior (not having
Set<A>
in B) the logique in my opinion should be in the generator not in the .json.Or maybe this case will juste disappear when the generators code starts using the .jdl as it's input, and if we want it back we will need to code the right way in the generator.
Motivation for or Use Case
This clearly can be avoided by changing the JDL, but it should be a known issue to avoid wasting other peoples time.
This is a bug because, the generated code does not compile
JHipster Version(s)
6.1.2 (don't think it's a regression) it's a side effect of adding fluent methods for add...