search

SAP / openui5

OpenUI5 lets you build enterprise-ready web applications, responsive to all devices, running on almost any browser of your choice.
http://openui5.org
Apache License 2.0
2.92k stars 1.23k forks source link

ODataListBinding: Filter cannot be applied to aggregated property #3997

Open tofriede opened 4 months ago

tofriede commented 4 months ago

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.

image

https://github.com/SAP/openui5/blob/2baad67a9dfdb39be38b027396d3646c57162d70/src/sap.ui.core/src/sap/ui/model/odata/v4/ODataListBinding.js#L1798

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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.

https://github.com/SAP/openui5/blob/26c34829f0d5869f6d6a85c4f5cf46489fcb911d/src/sap.ui.core/src/sap/ui/model/odata/v4/lib/_Helper.js#L1185

ThomasChadzelek commented 4 months ago

"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.