Chore: Remove composition of many for Genres

[etimr]

No description provided.

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[beckermarc]

Did the approach with the projection not work out? I'd prefer if we could keep the composition on db-level.

[agoerler]

Did the approach with the projection not work out? I'd prefer if we could keep the composition on db-level.

What is the purpose of this composition. If we decide that the Genres are not a single draft document but are editable individually then there should not be such a composition, I think.

[beckermarc]

What is the purpose of this composition.

Maintaining the integrity of the hierarchy and avoiding gaps, by ensuring deep deletes. I think from a conceptual level on database the hierarchy is a large document. How the document is exposed via draft to users is a different question I think. So I think we should be able to expose individual nodes of the hierarchy as individual documents by excluding the composition on service-level.

[agoerler]

by excluding the composition on service-level

or could we annotate it with @odata.draft.enclosed=false ?

[beckermarc]

by excluding the composition on service-level

or could we annotate it with @odata.draft.enclosed=false ?

No, this is not supported. @odata.draft.enclosed is only supported on associations and mainly intended to turn within-document-associations into draft-enclosed ones, if we don't detect that out-of-the-box.

[etimr]

Did the approach with the projection not work out? I'd prefer if we could keep the composition on db-level.

It works as expected. I think the question is more about the use case. If I get it correctly, we don't want to delete a Genre, we will leave this scenario just for reading. For modifications we want to introduce two more entities to cover Vincent's examples. One as a composition of many child for Books (like a table of contents with chapters) and another one for modifying similar to Genres but without any relationships to it from another entities.

[beckermarc]

Okay I still think it makes sense for scenarios where you want to enable editing of such hierarchies with drafts for individual nodes. If we however anyway won't use Genres as an example for write I don't see why we should remove the Composition that we had all the time. It makes sense from a modelling perspective.

BTW: Why not use Genres as an example for write with drafts for individual nodes? It would be a good fit from my perspective with the exclusion of the composition on service-level.

[etimr]

Decision regarding modeling of Genres in Bookshop:
books.cds

entity Genres : sap.common.CodeList {
    key ID       : UUID;
        parent   : Association to Genres;
        children : Composition of many Genres on children.parent = $self; 
} 

admin-service.cds

@odata.draft.enabled
entity GenreHierarchy as projection on my.Genres excluding {children};

Currently we are choosing to have a Cascade Delete with the easier possible way, Composition of many.

Depending on the relationships among the data, there are several possible scenarios:

• Cascade Delete of children if parent is deleted (modeling)
• Delete is allowed only for leafs, nodes with children are not deletable (custom logic)
• Delete of the parent means reassigning grandparent as a parent for the children nodes (custom logic)