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

Support ordinalIndex for collection complex or primitive #3103

Open
xuzhg opened this issue Oct 31, 2024 · 1 comment
Open

Support ordinalIndex for collection complex or primitive #3103

xuzhg opened this issue Oct 31, 2024 · 1 comment
Assignees

Comments

@xuzhg
Copy link
Member

xuzhg commented Oct 31, 2024

Short summary (3-5 sentences) describing the issue.

Assemblies affected

  • OData ABNF says

primitiveColPath = count / boundOperation / ordinalIndex
complexColPath = ordinalIndex
/ [ "/" qualifiedComplexTypeName ] [ count / boundOperation ]

ordinalIndex = "/" 1*DIGIT

Reproduce steps

So, suppose we have a collection primitive value properties as "Emails"

we should support:

~/odata/customers(1)/emails/0 --> returns the first email or not found
~/odata/customers(1)/emails/1 --> returns the second or not found
~/odata/customers(1)/emails/-1 --> returns the last email or not found

So, suppose we have a collection complex value properties as "Locations"

we should support:

~/odata/customers(1)/Locations/0 --> returns the first location or not found
~/odata/customers(1)/Locations/1 --> returns the location or not found
~/odata/customers(1)/Locations/-1 --> returns the last location or not found

~/odata/customers(1)/Locations/{index}/city --> returns the city property of location which is located at {index} of Locations?

Expected result

What would happen if there wasn't a bug.

Actual result

What is actually happening.

Additional detail

Optional, details of the root cause if known. Delete this section if you have no additional details to add.

@xuzhg xuzhg added the feature label Nov 5, 2024
@xuzhg xuzhg self-assigned this Nov 5, 2024
@xuzhg xuzhg added the P3 label Nov 5, 2024
@xuzhg
Copy link
Member Author

xuzhg commented Nov 5, 2024

It's waiting customers' requirements.
And there's a concern for the concurrency.

Suppose you get a item using the index, for example:

GET ~/odata/customers(1)/emails/2

then, some one deletes the third email using:

DELETE ~/odata/customers(1)/emails/2

Then, you use the original URI to fetch the third email is not the original email before the changes.

==> Design

  1. Basically, to keep concurrency is based on end user business logic. The end user can only allow 'GET', but disallow to 'DELETE', 'PATCH' using the index on the collection.
  2. From ODL perspective, ODL should allow parse the 'index' segment after collection. Then, the upper layer (the end user) can implement its logic based on the parsing result. Otherwise, the end user cannot benefit from it.

We can have more dicussion on it and looking forward more community feedbacks. @mikepizzo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant