Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XSLT, OData V2: no direct create for non-addressable entity sets #312

Merged
merged 6 commits into from
Oct 18, 2024

Conversation

ralfhandl
Copy link
Contributor

@ralfhandl ralfhandl commented Oct 10, 2024

Fixes #311

  • If entity set Foo is not addressable, no post operation for path /Foo will be generated
  • If it is creatable, a post operation for path /Parent(...)/to_Foo will be generated
  • If it is updatable or deletable, patch or delete will be generated as usual for path /Foo(...)

Plus

  • Remove leftover from unsuccessful experiment

@ralfhandl ralfhandl changed the title XSLT: no direct create for non-addressable entity sets XSLT, OData V2: no direct create for non-addressable entity sets Oct 10, 2024
@ralfhandl ralfhandl changed the title XSLT, OData V2: no direct create for non-addressable entity sets XSLT, OData V2: no direct create, update, delete for non-addressable entity sets Oct 10, 2024
@ralfhandl ralfhandl marked this pull request as ready for review October 17, 2024 11:40
@ralfhandl
Copy link
Contributor Author

@sterlp Can you please check if this is what you expect?

Note: I made the AddressSet creatable, updatable, and deletable to cover all cases.

<EntitySet Name="AddressSet" EntityType="ZE_API_DEMO_SRV.Address" sap:pageable="false"
sap:addressable="false" sap:content-version="1" />

@ralfhandl ralfhandl changed the title XSLT, OData V2: no direct create, update, delete for non-addressable entity sets XSLT, OData V2: no direct create for non-addressable entity sets Oct 17, 2024
@HeikoTheissen
Copy link

Why does /HeadSet('{BusinessPartner}')/to_Address appear for both HeadSet and AddressSet in Swagger?

AddressSet appears for PATCH and DELETE, but not for GET and POST (although it is creatable). Is that really what sap:addressable="false" means?

@ralfhandl
Copy link
Contributor Author

Why does /HeadSet('{BusinessPartner}')/to_Address appear for both HeadSet and AddressSet in Swagger?

Each operation is tagged with both the source and the target entity set, and in this case the two are different.

The same happens for example here:

@ralfhandl
Copy link
Contributor Author

AddressSet appears for PATCH and DELETE, but not for GET and POST (although it is creatable). Is that really what sap:addressable="false" means?

Yes, that is the historically grown meaning.

Originally sap:addressable="false" was invented for read-only CDS views with parameters:

  • The view parameters are specified as "keys" of the "parameter" entity set, the results are then retrieved by following the Set navigation property to the actual "data" entity set.
  • OData V2 does not have containment, so a top-level entity set for the "data" is needed. It is marked as sap:addressable="false" because it only allows indirect read access.

This then was later extended to writeable views:

  • Create is create-by-association only, and this was not correctly reflected by the XSLT and is fixed now.
  • Update and delete cannot be done via association because OData V2 defines that a two-segment path with two key segments is equivalent to a one-segment path with key segment addressing the target entity set, and this restriction is hard-wired into SAP NetWeaver Gateway for OData V2.

In OData V4 we use containment for CDS views with parameters, and all operations go via the "parameter" entity set and the containment navigation property Set.

@HeikoTheissen
Copy link

HeikoTheissen commented Oct 18, 2024

AddressSet appears for PATCH and DELETE, but not for GET and POST (although it is creatable). Is that really what sap:addressable="false" means?

Is the following reasoning correct?

Non-addressability removes the GET /AddressSet and POST /AddressSet, because there are the alternatives GET /HeadSet(...)/to_Address and POST /GET HeadSet(...)/to_Address. But there are no alternatives for PATCH and DELETE, so these remain.

If should be different if to_Address was a containment navigation property.

Copy link

@HeikoTheissen HeikoTheissen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wrong Swagger output for containment navigation properties

If I add

<NavigationProperty Name="to_Address" Relationship="ZE_API_DEMO_SRV.to_Address"
          FromRole="FromRole_to_Address" ToRole="ToRole_to_Address" sap:containstarget="true" />

then Swagger contains

HeadSet

  • PATCH /HeadSet(...)/to_Address(...)
  • DELETE /HeadSet(...)/to_Address(...)

AddressSet

  • PATCH /AddressSet(...)
  • DELETE /AddressSet(...)

The resource paths given for AddressSet are invalid, they must equal the resource paths given for HeadSet.

It doesn't work, and it is not documented
@ralfhandl
Copy link
Contributor Author

If should be different if to_Address was a containment navigation property.

Correct, and in OData V4 we use containment. In OData V2 there is no such thing.

@ralfhandl
Copy link
Contributor Author

Wrong Swagger output for containment navigation properties

Thanks for finding this, it seems this undocumented OData V2 Annotation was a left-over from an unsuccessful experiment.

@ralfhandl ralfhandl merged commit f0054e0 into main Oct 18, 2024
2 checks passed
@ralfhandl ralfhandl deleted the xslt/fix-not-addressable branch October 18, 2024 15:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Question/Bug: Not Addressable Entities and Path generation
2 participants