CDS Compiler 4.8.0 rejects function & action return types declared as 'many of many'?!

[DanielSchroeder]

Hello,

because of a failing deployment for a customer I found out that the latest (v4.8.0) CDS Compiler now rejects function/action return types that are declared as 'many of many'. This is outlined in the changelog.md file, which you can view on npmjs.com. While such a type may not be common in every piece of software, I firmly believe that this is a design choice that has to be made by the developer, not the cds compiler. Why was this change necessary?

Furthermore I find it very worrying that this kind of breaking change is done in a minor release. Also, why would this change be made just now? Some insight into the thought process towards this would be appreciated.

[RalfHandl · Accepted solution]

Hello Daniel,

This compiler change only affects compilation "to EDMX" and "to EDM JSON", that is generating OData $metadata.

OData does not yet support arrays of arrays, and a CDS model using them cannot be served with the OData protocol. This means the change is not breaking, it only surfaces a modeling problem earlier, shifting error detection to the left.

OData does allow arrays of structures whose elements can be arrays, which allows covering most use cases by adding an intermediate structure with an array-valued element. This intermediate structure has the benefit that it simplifies compatible extension of the API because sibling elements can be added on every level. Using arrays of arrays effectively prevents extensibility of the non-leaf arrays.

The OData Technical Committee is currently discussing support for arrays of arrays, see Github issue https://github.com/oasis-tcs/odata-specs/issues/279. Feel free to comment on this issue, ideally with an (abstracted) description of your use case to help us extend the standard in a way that meets your needs.

Does this answer your question?

Thanks in advance
Ralf

[DanielSchroeder · Accepted solution]

Thank you for the response!

So until now this was just a gap to the odata spec? Interestingly, we hadn't had any issues with our CAP function that used such an array of arrays. You've mentioned that this change shifts the error detection to the left, where should the error have occured previously? When calling the request handler?

[DanielSchroeder · Accepted solution]

Also, this means it crashes the CAP backend since CAP tries to compile the service metadata on startup, right?

[RalfHandl · Accepted solution]

.

[RalfHandl · Accepted solution]

I tried it with cds-compiler 4.7.6 and

  function foo() returns many test.manyString;

  type manyString : many String

This resulted in

  <Function Name="foo" IsBound="false" IsComposable="false">

    <ReturnType Type="Collection(test.manyString)" Nullable="false"/>

  </Function>

  <TypeDefinition Name="manyString" UnderlyingType="Edm.String"/>

The second "many" got lost when compiling to EDMX, meaning the service metadata claims that manyString actually is just a single string, so no array of arrays.

If you actually managed to respond with an array of arrays, then this is another bug that may need fixing.

[DanielSchroeder · Accepted solution]

Looking at the EDMX it looks exactly like in your example. Although the CAP Service actually sends an Array of Arrays, the type provided by the odata service boils down to Array of String. Looking into this, I even found another problem with the OData client I'm using, or rather the missing generation of the type of the function in question. For now I'll just remove the API Endpoint as it luckily isn't necessary at the moment.
Thanks a lot for your insights, this was very helpful to my understanding of the issue!

[RalfHandl · Accepted solution]

You're welcome! And please add your use case to OData TC issue https://github.com/oasis-tcs/odata-specs/issues/279 to give us real-world examples on which to test a potential specification extension.