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

Bound actions and function overloads via container and structured type #233

Open
wants to merge 22 commits into
base: main
Choose a base branch
from

Conversation

HeikoTheissen
Copy link
Contributor

@HeikoTheissen HeikoTheissen commented Jan 11, 2024

https://issues.oasis-open.org/browse/ODATA-1626

Path evaluation rules are already covered by the paragraph

For annotations hosted by an action, action import, function, function
import, parameter, or return type, the first segment of the path MUST be the
name of a parameter of the action or function or $ReturnType.

Copy link
Contributor

@ralfhandl ralfhandl left a comment

Choose a reason for hiding this comment

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

Please also consider the case via container on entity set or singleton without an additional property or navigation property before the action/function.

Also consider multi-segment paths for nested containment/structures

@HeikoTheissen
Copy link
Contributor Author

Please also consider the case via container on entity set or singleton without an additional property or navigation property before the action/function.

Also consider multi-segment paths for nested containment/structures

We don't have all these examples for the other cases either. Let's discuss this in the TC.

@mikepizzo
Copy link
Contributor

Shall we also allow schema-bound paths like

MySchema.MyEntityType/MyNavigationProperty/MyFunction

?

Yes.

@HeikoTheissen HeikoTheissen changed the title Bound actions and function overloads via container Bound actions and function overloads via container and structured type Jan 15, 2024
Comment on lines 691 to 692
Complex Type|have the type or a subtype thereof
Entity Type|have the type or a subtype thereof
Copy link
Contributor Author

Choose a reason for hiding this comment

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

MySchema.MyEntityType/MySchema.MyAction(MySchema.MyEntityType)

is equivalent to MySchema.MyAction(MySchema.MyEntityType) but

MySchema.MyEntityType/MySchema.MyAction

has a meaning of its own. Is it OK to allow both?

@HeikoTheissen
Copy link
Contributor Author

What about targets like

MySchema.MyAction/$ReturnType/PropertyOfMyComplexReturnType

?

Comment on lines +695 to +699
A binding parameter is "addressed via a resource path" if the path expression addressing the
binding parameter starts with the resource path, it may then continue with segments
described in [OData-URL](#ODataURL), sections 4.6 through 4.12. If the resource path
addresses a collection, the binding parameter can also be a single instance of that
collection if a segment described in [OData-URL](#ODataURL), sections 4.9 and 4.10, follows.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Does the annotation target

MySchema.MyContainer/MyEntitySet/MySchema.MyAction

address the bound action

POST MyEntitySet/MySchema.MyComposableFunction()/MySchema.MyAction

even if the composable function returns a different entity set?

Copy link
Contributor

Choose a reason for hiding this comment

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

I would expect that it does not, instead I'd expect that annotations for target
MySchema.MyContainer/MyOtherEntitySet/MySchema.MyAction apply if function MySchema.MyComposableFunction returns entities from MyOtherEntitySet.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

instead I'd expect that annotations for target
MySchema.MyContainer/MyOtherEntitySet/MySchema.MyAction apply if function MySchema.MyComposableFunction returns entities from MyOtherEntitySet.

Which is the case according to the first table row:

Model element means the binding parameter must be
Entity Set an instance or collection of instances from the entity set

Copy link
Contributor Author

Choose a reason for hiding this comment

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

But the target

MySchema.MyContainer/MyOtherEntitySet/MyContainmentNavigationProperty/MySchema.MyAction

would not apply if the composable function returned entities from the contained entity set.

Must we distinguish between containment and non-containment navigation properties? Currently we have only

Model element means the binding parameter must be
Navigation Property via container addressed via a resource path to the navigation property

Copy link
Contributor

Choose a reason for hiding this comment

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

If the function returns totally unrelated entities, we can't express that (yet) in $metadata.

If the function returns related entities and is defined with

EntitySetPath="__it/_otherEntity/MyContainmentNavigationProperty"

then the client could figure out look for annotations with target

MySchema.MyContainer/MyOtherEntitySet/MyContainmentNavigationProperty/MySchema.MyAction

That is asking a lot, and I feel we are down a very exotic rabbit hole.

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.

Should support annotations to bound actions/functions via path
3 participants