New interop structure, types and precision information

[dritter-sap]

We reworked the current interop as agreed into three parts (splitting spark and dsp):

• spark
• dsp

and added a type mapping for hana

• hana

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ Fannon
❌ dritter-sap
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[jalberti]

Thank you for your contribution, it is greatly appreciated!

May I suggest that when introducing new types, a new source, please start with a new document, see ABAP example, introducing first the types of the source system, mapping them into CDS types, and optionally provide their Spark equivalents, with respective cast instructions. Then, for any CDS types, we can introduce a mapping into a target type system.

The Spark type document needs work that aligns with this strategy. We can work on this in a distinct separate PR.

Thank you!

[Fannon]

@dritter-sap : Thanks for bringing this up. I think we need to discuss it in CSN Interop WS, we already did it to some degree.

First, like @jalberti mentioned the types would first need to get introduced into the CSN Interop Types itself.

But here I see a problem: Types like hana.* are by definition not interoperable. So if we need types here, we need to generalize them so it's not Database specific. Also, we need to be VERY careful when introducing new types, as consumers who do not expect them to come up might break.

In most cases it would be safer to work with annotations here that could guide how a Database maps it to its own type. This is also how JSON Schema works: There are only a few real technical types that are completely stable. The rest is describes with "format" and via constraints like "maxValue".

FYI, @andreasbalzar

[Fannon]

We can't introduce hana.* types into the CSN interop specification, because they are by definition not Interoperable - they are HANA DB specific.

[dritter-sap]

that is reworked, kindly check.

[amitcseiitb]

Our proposal is to support this with cds.Decimal (precision = p, scale = floating) gets mapped to STRING in delta. Do you want to add this in the current PR or a later one?

[amitcseiitb]

Same for cds.Decimal (no arguments)

[amitcseiitb]

new proposal to map cds.Vector to delta STRING.

[amitcseiitb]

HANA type SMALLDECIMAL seem to be not in the list. But I think, it may be fine to not include for now as there is no CDS type associated with it and so anyway CAP consumer/producer of DP can not consume/produce such type.