You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The compositions translate to the composition name, rather than the corresponding entity or aspect name. As a result duplication issues might occur when the same composition name is used, while pointing to two distinct aspects or entities.
Using the entity or aspect name, rather than the composition name looks like
Example data model definition:
namespace my.bookshop;
entity Books {
key ID : Integer;
title : String;
stock : Integer;
Attributes : Composition of many Book_Attributes;
}
aspect Book_Attributes {
key code : String(10);
bookValue : String;
}
entity CDs {
key ID : Integer;
title : String;
stock : Integer;
Attributes : Composition of many CD_Attributes;
}
aspect CD_Attributes {
key code : String(10);
cdValue : String;
}
Books and CDs has a similarly named composition, but refer to two distinct aspects (entities). However, when the types are being created, the name of the composition is used, rather than the name of the corresponding entity.
Below is the result of the data model definition above.
Notice the duplication of the IAttributes interface definition, as well as the Entity and SanitizedEntity enum.
A current workaround that can be used is to ensure unique composition naming with the corresponding namespace.
The underlying issue, I think is the interpretation between a composition of an Entity versus the composition of an Aspect. In case of an entity, the target of the definition in csn is the reference entity name. In case of an aspect, the target of the definition is my.bookshop.Books.Attributes and there is an additional target_aspect field that contains the name of the aspect. The cds2types conversion (resolveTargetType) for the composition seems to be based on the target name, which provides the right information. However, the name is sanitized and only retains the last part of the name, separated by periods.
In the above example, the same composition name results in duplicate definitions.
The text was updated successfully, but these errors were encountered:
frankmeertens
changed the title
Composition translates to composition name, rather than corresponding entity
Duplicate type definitions generated for compositions to aspects
Jul 26, 2022
The compositions translate to the composition name, rather than the corresponding entity or aspect name. As a result duplication issues might occur when the same composition name is used, while pointing to two distinct aspects or entities.
Using the entity or aspect name, rather than the composition name looks like
Example data model definition:
Books and CDs has a similarly named composition, but refer to two distinct aspects (entities). However, when the types are being created, the name of the composition is used, rather than the name of the corresponding entity.
Below is the result of the data model definition above.
Notice the duplication of the
IAttributes
interface definition, as well as theEntity
andSanitizedEntity
enum.A current workaround that can be used is to ensure unique composition naming with the corresponding namespace.
The underlying issue, I think is the interpretation between a composition of an
Entity
versus the composition of anAspect
. In case of an entity, thetarget
of the definition incsn
is the reference entity name. In case of an aspect, thetarget
of the definition ismy.bookshop.Books.Attributes
and there is an additionaltarget_aspect
field that contains the name of the aspect. Thecds2types
conversion (resolveTargetType
) for the composition seems to be based on thetarget
name, which provides the right information. However, the name is sanitized and only retains the last part of the name, separated by periods.In the above example, the same composition name results in duplicate definitions.
The text was updated successfully, but these errors were encountered: