added limitations for compositions of one #729
Conversation
Co-authored-by: Dr. David A. Kunz <[email protected]>
There was a problem hiding this comment.
I would approve this from my side, but as a remark: I would go even further as to completely discourage the use of composition of one outside of legacy porting, meaning that if you don't have an existing DB model to map to, then this construct shouldn't be used at all. The existing formulation is a lot more friendly, ut also catches the gist of it
|
@renejeglinsky , @smahati could you please take a look? |
cds/cdl.md
Outdated
| Using of compositions of one is discouraged. There is often no added value of using them as the information can be placed in the root entity. Compositions of one have limitations as follow: | ||
| - Very limited Draft support. Fiori elements does not support compositions of one unless you take care of their creation in a custom handler. | ||
| - No extensive support for modifications over paths if compostions of one are involved. You must fill in foreign keys manually in a custom handler. |
There was a problem hiding this comment.
I think this depends very much on wether we are talking about a composition of one entity or a composition of one aspect.
The may in difference is that for a composition of one entity the foreign key is on the parent side where as for a composition of one entity the foreign key is on the target side. This makes compositions of one aspect more friendly wrt. modifications over paths.
There was a problem hiding this comment.
I'm not a runtime expert, but my assumption is that the restrictions mentioned here only apply to "composition of one entity" - correct?
|
Here I find composition of one aspect explicitly mentioned: https://cap.cloud.sap/docs/cds/cdl#default-target-cardinality |
required in an external ticket