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
cds-typer nowadays uses two flavours of CSN to operate: xtended and inferred flavour.
The inferred flavour is generally superior in our case, as it contains fields that are computed later down the pipeline, like properties from CQN selections, annotations, and so on. These are all fields we are expecting in our generated type files.
The xtended flavour on the other hand does not propagate fields from inherited entities to child entities. Consider the following CDS file:
This duplicate is not present when using the xtended flavour instead.
Ramifications
As the compilation step is not discrete and/pure, we need to load the entire model twice. This can be a considerable hit on the execution time.
Having both flavours can also be rather confusing. We constantly need to juggle them and remember which flavour to use in which use case.
Suggested Solution
We should get rid of one of the two flavours. As inferred CSN is more complete, the xtended flavour should probably be dropped. Instead of rectifying the xtended flavour with unrolled annotations, we should aim to deduplicate properties in the inferred flavour instead.
Alternatives
Wait for universal CSN or modify xtended CSN even more to be closer to inferred CSN.
Additional Context
No response
The text was updated successfully, but these errors were encountered:
Description
Two Flavours
cds-typer nowadays uses two flavours of CSN to operate: xtended and inferred flavour.
The inferred flavour is generally superior in our case, as it contains fields that are computed later down the pipeline, like properties from CQN selections, annotations, and so on. These are all fields we are expecting in our generated type files.
The xtended flavour on the other hand does not propagate fields from inherited entities to child entities. Consider the following CDS file:
Loading it with the inferred flavour will generate this CSN snippet:
which would (more or less) result in the following classes:
This duplicate is not present when using the xtended flavour instead.
Ramifications
As the compilation step is not discrete and/pure, we need to load the entire model twice. This can be a considerable hit on the execution time.
Having both flavours can also be rather confusing. We constantly need to juggle them and remember which flavour to use in which use case.
Suggested Solution
We should get rid of one of the two flavours. As inferred CSN is more complete, the xtended flavour should probably be dropped. Instead of rectifying the xtended flavour with unrolled annotations, we should aim to deduplicate properties in the inferred flavour instead.
Alternatives
Wait for universal CSN or modify xtended CSN even more to be closer to inferred CSN.
Additional Context
No response
The text was updated successfully, but these errors were encountered: