-
Notifications
You must be signed in to change notification settings - Fork 741
Update query-over.md #9735
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
base: development
Are you sure you want to change the base?
Update query-over.md #9735
Conversation
I tried to make it understandable but the terminology and the wording could be a bit off. |
One more thing. The only real issue here is that originally instead of But if you think the original wording is fine then you can also only replace |
Thanks - I'm having a look now, but trying to read the whole document so I have some context. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR and the explanation of why it is needed.
I think I understand the issue and have made a couple of comments below. Let me know if you think they make sense.
In this example, a list of **Specializations** cannot be retrieved when using a standard by-association retrieve in a microflow if the input is the specialization. | ||
|
||
However, there is a workaround for this limitation: The list of Specializations can be retrieved with a Java action using the Java API. This Java action needs two parameters: the **Specialization** and a Boolean **Reverse** via this code snippet: | ||
In this example, if a standard by-association retrieve in a microflow is used starting from a `Specialization` this will return the `Specialization` that the starting point `Specialization` points to. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to be clearer that you do not get the generalization. How about:
In this example, if a standard by-association retrieve in a microflow is used starting from a `Specialization` this will return the `Specialization` that the starting point `Specialization` points to. | |
In this example, if a standard by-association retrieve in a microflow is used starting from a `Specialization` this will return the `Specialization` that the starting point `Specialization` points to and not the list of `Generalization` which are associated via the `Generalization_Specialization` association. |
@@ -104,9 +104,8 @@ Here is an example inheritance: | |||
|
|||
{{< figure src="/attachments/refguide/modeling/domain-model/associations/query-over/limitation.png" class="no-border" >}} | |||
|
|||
In this example, a list of **Specializations** cannot be retrieved when using a standard by-association retrieve in a microflow if the input is the specialization. | |||
|
|||
However, there is a workaround for this limitation: The list of Specializations can be retrieved with a Java action using the Java API. This Java action needs two parameters: the **Specialization** and a Boolean **Reverse** via this code snippet: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is worth putting a text description of the Java as well.
But on a more general note, however - although my programming days are about 30 years in the past, I'm not so happy with the class name or that the reverse is a parameter to it.
Would it not be better to have a class called RetrieveGeneralizationViaAssociation which is just dedicated to doing that (and perhaps name the object something more meaningful than B
?
Perhaps this is clearer to a Java developer, but this might be needed by a low-code developer whose Java skills are as weak as mine.
If the customer wants to implement a more general-purpose version, then they can adapt the simple version?
No description provided.