How to model a 1:n relationship in CAP

[ceedee666]

Hi all,

I was playing around with CAP a little bit and tried to model a 1:n relation in my data model. For example consider an order and order items. What I try to express in the data model is that there needs to be at least on item for each order. According to the the documentation this should be possible using constraints (https://cap.cloud.sap/docs/guides/domain-models#associations):

Simply add the keyword many to indicate a 0..* cardinality. Express and check all additional restrictions about cardinality, such as min 1 or max 2, as constraints, for example, using not null.

However, no matter where I put the constraint on an association, I always get an error message. I also tried to use a composition to model the 1:n relationship. But compositions behave just like associations with respect to cardinality. They do also allow 0:n relations (i.e. i can create a order without an item in my example).

Does anyone know how to model other relationships than the standard 0:n ones in CAP?
Christian

[lbreddemann]

I don't think you're missing anything, Christian.

My understanding is that CAP does not model referential constraints as constraints of what could be created. Instead, the association concept seems to declare how entities (and their table representations) can be read correctly.

So it's more like a guideline than the hard law of database referential constraints.

My guess here is that this closely resembles how ABAP systems implemented data dependencies on DB level, i.e. they don't implement them on DB level at all. And there are obvious benefits that come with this, the option for deferred "updater" processing and higher throughput while writing data being two of them.

The downsides of this are of course equally well known (potential for data inconsistencies).

Now, to me the question is of course: does it actually matter in real life? If the order-items are always read via the CDS association then the ones without a matching order will simply be ignored.

Same should happen for orders w/o any items (I'm simply hoping that the [1,...] association gets translated into an INNER join here. Haven't tested that yet explicitly).

That means, that while one could create nonsense entries, the "reading-rules" encoded in the CDS models would avoid returning those.

This is at least my train of thought here.

[ceedee666]

Hi Lars,

I agree with you, that the behavior I found would most likely not matter in real life. Furthermore, I would argue, that constraints like e.g. 1:3, don’t belong on the DB level but rather in the application level. However, IMO the documentation is currently misleading in this respect and should be clarified.

I’m wondering why the constraint are the CDS if they are not used. It might be that different translations of the CDS behave differently (I only tested with SQLite so far). Or that it is something for future extension.

Regarding the translation of 1:n into an inner join: this is not happening as far as I can tell. I created service for the two entities and were able to read orders without items. Even when I explicitly expanded the relation using OData $expand, all order where returned.

Christian