ODataListBinding: Filter cannot be applied to aggregated property

[tofriede]

OpenUI5 version: 1.121.0

Browser: Google Chrome

URL (minimal example if possible): https://github.com/tofriede/odata-v4-filter-aggregation

Steps to reproduce the problem:

1. Create a sap.ui.model.odata.v4.ODataListBinding
2. Aggregate a numeric property
3. Apply a sap.ui.model.Filter based on the aggregated property

What is the expected result?

The list binding should execute an OData request with the query option $apply, in which the data is aggregated first and then the corresponding filter is applied. The fact that this should be possible is also mentioned in the documentation under Extension for Data Aggregation (section: Filtering).

What happens instead?

Before the request is fired, the ListBinding analyzes the applied filter and tries to determine the type of the aggregated property via the MetaModel. However, this fails because an alias must be used for the aggregation that is not known to the MetaModel, as this is defined on the client side.

openui5/src/sap.ui.core/src/sap/ui/model/odata/v4/ODataListBinding.js

Line 1798 in 2baad67

return oMetaModel.fetchObject(sResolvedPath).then(function (oPropertyMetadata) {

Since the mapping of aliases and original property names is known to the ListBinding (getAggregation), it should also be able to identify the types of aggregated properties.

[ThomasChadzelek]

Hello @tofriede !

Thanks a lot for using OData V4. We apologize for any inconvenience caused.

I confirm the issue you describe. In the meantime, please try to use the system query option $filter : "UnitPrice_avg gt 30"

Best regards,
Thomas

[ThomasChadzelek]

Our current thinking is that we cannot fix this as a bug easily. The needed type is not at all clear from the information we have. The average of an Edm.Int would normally not be an integer value as well. The OData response will contain the type information, but that is too late. Maybe it can be enhanced in future (and CPOUI5ODATAV4-2518 has been created to keep track of this), but as a next step, we should first improve our docs. Thanks for your understanding.

[tofriede]

Hello @ThomasChadzelek!

Thanks for the quick response. As far as I can see, the type is only needed to convert the filter values to a suitable literal that is used in the odata url. Since all numeric values are treated the same here (no quotes), using the type of the original property should not cause any problems. The exact type is not really needed at this point.

openui5/src/sap.ui.core/src/sap/ui/model/odata/v4/lib/_Helper.js

Line 1185 in 26c3482

formatLiteral : function (vValue, sType) {

[ThomasChadzelek]

"Since all numeric values are treated the same here (no quotes)" - well, that is no strictly true, see Edm.Decimal and Edm.Int64 which are handled as strings in order to avoid loss of precision. But thanks for your suggestion, I will take note and see what we can do about it.