Show TOC

Changes Compared to OData V2 ModelLocate this document in the navigation structure

This section outlines the main differences between the OData V2 and OData V4 models.

While some of the differences between the OData V4 model and the OData V2 model are due to features that have not yet been implemented, many differences are due to the following:
  • Protocol incompatibility between OData V4 and OData V2

  • API cleanup and simplification

  • Adherence to OData V4 standards regarding the names and terms used in APIs

These differences will therefore remain even after all features have been implemented. The table below gives you an overview of these changes, as well as the reason behind them and (if applicable) how the OData V2 model mechanism is supported in the OData V4 model.



Binding parameter names: The binding parameter name for an OData system query option is identical to the system query option name: $expand, $select, ... (V2 uses expand, select).

Simplification: The OData V4 model simplifies the binding parameter structure to just one map where all entries in the map are OData query options, with the exception of entries that have a key starting with "$$" (binding-specific parameters). In all cases, the names of the binding parameters are exactly the same as in the OData URL sent to the server.

No synchronous access to data via the model: Model does not support the methods getData, getObject, getOriginalProperty, getProperty.

OData requires asynchronous data retrieval: Synchronous data access requires that data has already been loaded from the server. This means there is no way of knowing whether this already happened, meaning the result of a synchronous access method is quite often unpredictable.

Minimize APIs required for batch control: Model does not support the methods getChangeBatchGroups, getChangeGroups, getDeferredGroups, setChangeBatchGroups, setChangeGroups, setDeferredBatchGroups, setDeferredGroups, setUseBatch (and corresponding model construction parameters).

Simplification: Batch groups are solely defined via binding parameters with the corresponding parameters on the model as default. Application groups are by default deferred; there is no need to set or get deferred groups. You just need the submitBatch method on the model to control execution of the batch. You can use the predefined batch group "$direct" to switch off batch either for the complete model or for a specific binding (only possible for the complete model in V2).

OData operations executed via binding: Model does not support the method callFunction.

Simplification: Use an operation binding instead; it is now much easier to bind operation execution results to controls.

No CRUD methods on model: Model does not support the methods create, read, remove, update.

Simplification: read and update operations are available implicitly via the bindings, so that changes are bound to controls. It is not possible to trigger requests for specific OData URLs. create and remove are not yet supported.

No metadata access via model: Model does not support methods getServiceAnnotations, getServiceMetadata, refreshMetadata as well as methods corresponding to the events metadataFailed, metadataLoaded.

Simplification: Metadata is only accessed via ODataMetaModel. Metadata is only loaded when needed (e.g. for type detection or to compute URLs for write requests); the corresponding methods on the v4.ODataMetaModel use promises instead of events.

sap.ui.model.odata.AnnotationHelper is not supported for OData V4.

Simplification: All supported functionality of sap.ui.model.odata.AnnotationHelper is provided by sap.ui.model.odata.v4.ODataMetaModel and sap.ui.model.odata.v4.ODataModel