About the refresh method of SAP UI5 OData V4 model

The SAP UI5 OData V4 model includes the following three binding instances:

• List Binding
• Context Binding
• Property Binding

No matter what type of data binding instance, it creates a data service request, these binding instances will design a cache to store the data of the data service response. These binding instances will not send data service requests again if data can be provided from this cache.

Application developers can use the refresh method to delete the cache of absolute bindings. This method also removes the cache of absolute bindings' child bindings.

When the refresh method is called, the binding and its child bindings must not have pending property changes, the so-called pending property changes .

Use the binding's hasPendingChanges method to check for changes of this type before deleting the cache.

one example:

 onRefreshSelectedSalesOrder : function () {
    // within a sap.m.Table bound to a OData V4 list binding get the OData V4 context for the selected entity
    var oSalesOrderContext = this.byId("SalesOrders").getSelectedItem().getBindingContext();
      
    if (!oSalesOrderContext.hasPendingChanges()) {
        oSalesOrderContext.refresh();
    }
},

After updating an entity, it may no longer match the query options for the collection that loaded the entity, specifically $filter. You can decide whether refreshing the context of a list binding should ignore query options: by setting the parameter bAllowRemoval to true, the corresponding context can be removed from the list binding of the collection.

It's important to note that changes to the list (such as a different sort order) require the entire list to be refreshed.

Below is an example. The Table control in this app has a filter applied to only show sales orders with a lifecycle state of New . When the sales order is confirmed, its status will change to In Process and no longer match the filter. The sales order is then refreshed and removed from the list when the bAllowRemoval flag is set to true.

The code for the above logic is as follows:

 oAction.execute("confirmSalesOrderActionGroup").then(function () {
    oConfirmedSalesOrderContext.refresh(undefined, true); // bAllowRemoval = true
});

Example of using absolute path binding in XML view and specifying additional query option:

 <Table items="{
 path : '/SalesOrderList',
 parameters : {
  $expand : 'SO_2_BP',
  $select : 'BuyerName,CurrencyCode,GrossAmount,Note,SalesOrderID'
 }}">
 ...
 <items>  
  <ColumnListItem>
   <cells> 
    <Text text="{SalesOrderID}"/> 
    <Text text="{SO_2_BP/CompanyName}"/>
    <Text text="{BillingStatus}"/> 
   </cells>
  </ColumnListItem>

 </items>
</Table>

<Table items="{
 path : 'SO_2_SOITEM',
 parameters : {
    $select: "DeliveryDate,GrossAmount,SalesOrderID"
 }
>
...
</Table>

The above example shows an absolute list binding: the item aggregation of the table is bound to /SalesOrderList using the $expand and $select query options as binding parameters. These columns define relative bindings with paths SalesOrderID, SO_2_BP/CompanyName, and BillingStatus, with absolute list bindings as parent bindings.

The second table control in the XML view above, the table control that displays row items, uses relative binding syntax. Since it defines parameters, once it receives its binding context, it triggers its own data service request.