You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@olingo.apache.org by Ronny Bremer <rb...@almanid.com> on 2022/04/20 14:55:58 UTC

OData V4 schema, entity keys and group by

Expanding our current Olingo v4 (4.9.0) based server implementation I came across an issue, which I am not sure how to tackle.

Lets assume, we have an Entity with a minimal data set of:

ID: int
Name: string
Version: int
Category: int

Where the EDM sets ID as the key and Name as mandatory.

Reading the collection is fine, as it returns all values which are filled, including the key.
http://localhost/odata/TestSet?$filter=Version eq 10

Would return:
ID: 1, Name: test1, Version: 10, Category: 6
ID: 3, Name: test3, Version: 10, Category: 1
ID: 9, Name: test9, Version: 10, Category: 1


Now I am implementing group by functions. The URL would be:
http://localhost/odata/TestSet?$filter=Version eq 10&$apply=groupby((Category),aggregate($count as Count))

After successful parsing the request, collecting the aggregated data, I end up with a list of Map<String, Object>, which obviously have nothing to do with the original EDM of the set.
For example, this is what I convert into entities for the request:
Category: 6, Count: 1
Category: 1, Count: 2

Clearly, there is no ID and no Name present as they are not part of the group by clause. The library, however, is automatically adding the alias “Count” to the list of properties for the request and the result, as this URL is accepted:
http://localhost/odata/TestSet?$filter=Version eq 10&$apply=groupby((Category),aggregate($count as Count))&$select=Category,Count&$orderby=Count

After building the result set the library complains about missing key on each entity, missing Name as a mandatory field.

My question is, should the library be aware of the fact, that the request contained aggregation functions and therefore will not be checked against the EDM? Or is there something I need to do in order to make the happen?

I do remember, that the /odata/TestSet/$count URL is implemented via a different interface, returning only an int which obviously is not checked against the EDM.

Thank you for any comments or suggestions.

Ronny