Changes Compared To OData V2 Model Abd4d7c

You might also like

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 2

loio

abd4d7c7548d4c29ab8364d3904a6d74
view on: demo kit nightly build | demo kit latest release

Changes Compared to OData V2 Model


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.
Warning: The below table contains complex elements that cannot not be displayed within a simple markdown
table. It has been automatically converted to an HTML table. It’s design may vary from the source page!
Change
Reason
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.</td>
</tr> <tr> <td>The model does not support the methods `getData`, `getObject`,
`getOriginalProperty`, `getProperty`. For data access, use the context API instead of
methods on the model.</td> <td>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. The OData V4 context API offers
ansynchronous and synchronous access to the data of a specific context. It is no longer
necessary to construct a path for data access as needed by the methods on the model. For
more information, see the section *Context API* in [Bindings](Bindings_54e0ddf.md).</td>
</tr> <tr> <td>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\).</td> <td>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\). For more information, see [Batch
Control](Batch_Control_74142a3.md).</td> </tr> <tr>
<td>OData operations executed via binding: Model does not support the
methodcallFunction.</td> <td>Simplification: Use an operation
binding instead; it is now much easier to bind operation execution results to
controls.</td> </tr> <tr> <td>No CRUD methods on
model: Model does not support the methods create,read,remove,update.</td>
<td>Simplification:read,update,createandremoveoperations are available
implicitly via the bindings. Bindings can also be used without controls. It
is not possible to trigger requests for specific OData URLs. For more
information, see [Accessing Data in Controller
Code](Accessing_Data_in_Controller_Code_17b30ac.md).</td> </tr>
<tr> <td>No metadata access via model: Model does not support
methodsgetServiceAnnotations,getServiceMetadata,refreshMetadataas well as methods
corresponding to the eventsmetadataFailed,metadataLoaded.</td>
<td>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: Much of the functionality in sap.ui.model.odata.AnnotationHelper is
provided by sap.ui.model.odata.v4.ODataMetaModeland
sap.ui.model.odata.v4.ODataModel.
Note: The path syntax supported by the v4.ODataMetaModel, see sap.ui.model.odata.v4.ODataMetaModel,
method requestObject allows for navigation in the model’s metadata; there is no need to use
AnnotationHelper methods for this. You can find the remaining functionality in the OData V4 specific
sap.ui.model.odata.v4.AnnotationHelper.

Related information
sap.ui.model.odata.AnnotationHelper
sap.ui.model.odata.v4.ODataMetaModel
sap.ui.model.odata.v4.ODataModel

You might also like