Hi there,
we’re currently upgrading our A12 version to 2024.06 and as we have to generate DocumenModels we’re doing lots of “modelling” directly on the .json files.
With the upgrade to Modelversion 28.0.2 the declaration of Computations changed. Instead of a “computedFieldId” there is now a new attribute: “computedFieldRelPath” which according to its name should refer to the relative path of the computed field.
However I am of the opinion that the path is incorrect. If I address fields in the “operation” that are in the same group as the computed field the name of the field is used. If I address a field that is outside the group where the computation is located the field name is prefixed with “../”. However the reference to the computed field always contains at least one “../” even though the field is inside the same group as the computation.
See:
Is there a reason for this inconsistency?
Best regards,
Philipp
Hello,
Sorry for late reply. I spoke with Kernel team and they will have a look and provide the answer.
Hi @philipp-mild-glyph,
the Kernel-team introduced the difference because the “new” way to reference the computedField in a computation or the errorField in a rule reduces the complexity in other functionalities, such as move support (e.g. when you move a field, the affected rules should be adapted automatically whenever it is possible), include resolution or ADS mechanism.
We did not want to change the way the entites are referenced in the rules and computations since that change would have affected the modelig experience, whereas the change in computedField / errorField should not.
Hi @gildardo-cached-canyon,
thanks for the explanation. I was aware of the intention of the change however the reference seems incorrect to me. Disregarding how I setup the computation, I will always end up having the “computedFieldRelPath” starting with “…/”.
Let me give you an example which is a bit less complex than the first one:
In the root of “MyEasyDocumentModel” I have a group called “group_A” and a computation called “myComputation”. Inside the “group_A” you will find two fields: “computedField” and “field_used_for_computation”.
The computation “myComputation” inside the root group refers to “computed_Field” via the “computedFieldRelPath” and it uses the “field_used_for_calculation” in the “operation” of the only compuationAlternatives entry.
If you now compare “computedFieldRelPath” and “operation” you will see that computed field reference starts with “../group_A/” whereas the field reference inside the operation starts with “group_A/”. I would have expected both to start with “group_A/” as both fields are in the same group.
Even though it does not affect modelling via SME or the execution of the computation it still is a Bug in my opinion.
Best regards,
Philipp
@philipp-mild-glyph: Thanks for your reply, now I know that I forgot to explain the following:
- The “new” way to reference
computedFieldRelPath is relative to the referencing element itself. In your example, the referencing element is “/root/myComputation” and if you add the referenced entity, you get “/root/myComputation/../group_A/computed_Field” which resolves to “/root/group_A/computed_Field” (the entity you want).
- The way to reference entities in rule conditions, (common) preconditions and operations is relative to the corresponding
RuleGroup (computation group). In your example, the “computation group” is “/root” and if you add the referenced entity in the operation, you get “/root/group_A/field_used_for_calculation” which is the entity you want.
To explain why the “new” way to reference the entities reduces the complexity would go to much in the implementation details. Thanks once again for the hint, but I can assure that this is not a bug.
Cheers,
Gil
Hi @philipp-mild-glyph,
did the reply from @gildardo-cached-canyon answer your question or do you need further support? If it is solved, please, use the checkbox to mark the solution to your problem so that other users also know what helped in your case.
Thanks in advance!
Denise from the Discourse team
Hi @denise-narrow-token,
thanks for the reminder
I guess @gildardo-cached-canyon answered the question properly.
So as I understand a computation is treated as a group where the pointer needs to jump out to refer to the field however the calculation itself does not need to do that.
