Closed fabiocarvalho777 closed 2 years ago
@fabiocarvalho777 Can you specify how the user will specify ignore for inner values?
For eg: if response type is {booleanVar complexField {innerBooleanVar innerIntVar innerStringVar} intVar stringVar} How will I specify ignore for innerBooleanVar and innerStringVar Also are we supporting to ignore the inner class itself as a whole?
For eg can we specify ignore to be complexField somehow which should ignore all its inner values? I need clarity on some of these cases.
{
booleanVar
complexField {
innerBooleanVar
innerIntVar
innerStringVar
}
intVar
stringVar
}
Given the response type above, to ignore innerBooleanVar
and innerStringVar
, ignore
should be set to {"complexField.innerBooleanVar", "complexField.innerStringVar"}
. Please, as I said before, take a look at how ignore works and is documented for Var
annotation. The format here is identical to that.
Also are we supporting to ignore the inner class itself as a whole?
Yes, we are. If we want to ignore complexField
, all we have to do is set ignore
to "complexField"
.
Let me know if you have other questions. Thanks.
Thanks for clarifying @fabiocarvalho777
3. If annotation is present and both `value` and `ignore` attributes are **NOT** set, then a `MoccaException` is thrown.
Why don't we simply not allow this instead of exposing our users to runtime exceptions? Is a different annotation design (e.g. 2 different annotations) not an option? I don't know that much about 'selection sets', so forgive my ignorance.. Just trying to help with the PR review.
3. If annotation is present and both `value` and `ignore` attributes are **NOT** set, then a `MoccaException` is thrown.
Why don't we simply not allow this instead of exposing our users to runtime exceptions? Is a different annotation design (e.g. 2 different annotations) not an option? I don't know that much about 'selection sets', so forgive my ignorance.. Just trying to help with the PR review.
Having two different annotations could be an option. There are some cons in this approach too. For example, what if the user uses both annotations at the same time? Wouldn't we have to check and prevent that in runtime anyways? How would we name both annotations? Could it be confusing for users to have two instead of one? Could it make the logic that process the annotations more complex?
So, when I think about the pros and cons, I think having one annotation sounds better, although not ideal.
What do you think?
I definitely think we can run with this as-is and let users complain.
Of your questions, the first one gives me the most pause. I am assuming we could come up with good names, but that worries me a bit as well. Honestly, I was thinking more about types (classes) when I made those comments. I haven't built many things where I leveraged annotations. Anyhow, if we ever revisit, here are some options that could be considered:
Again, I don't think this is required. I have a mild itch to investigate, but sadly time will likely not permit it.
Add a new use case for
SelectionSet
annotation where users can still let Mocca resolve the selection set automatically, using the response DTO declared in the method return type, however, ignoring fields specified in a new attribute, calledignore
, to be added toSelectionSet
.SelectionSet would then behave like this:
value
attribute is set, Mocca automatic selection set resolution is turned off, andSelectionSet
value
is used to define the selection set. In this case ifignore
value is also set, then that is not used by Mocca, and a warning is logged.value
attribute is NOT set, butignore
is, then Mocca automatic selection set resolution is turned ON, andSelectionSet
ignore
is used to pick which response DTO fields to ignore from the selection set.value
andignore
attributes are NOT set, then aMoccaException
is thrown.Important Note
The fields marked to be ignored must NOT be present in the selection set defined in the request message! This might sound obvious but it is important to emphasize it to make sure the code changes pushed for this issue don't remove those fields only after the server already returned a response with them.
Acceptance Criteria