关于前端:如何使用-SAP-UI5-V2-ODataModel-模型-API-实现-deepCreate-的场景以及局限性

如果开发人员冀望在长久化时申请已创立条目标导航属性(navigation property)，请应用可选的 expand 参数在与实体创立的 POST 申请雷同的批处理申请中无效地执行此操作。

可选的 inactive 参数确定是否创立非流动 transient 上下文。这样的上下文只会在属性更新时成为流动的 transient 上下文。在此之前，它不是挂起的更改，即它不被 hasPendingChanges API 思考，也不能被 resetChanges 删除；submitChanges API 不会触发非流动上下文的创立申请。

deepCreate，即首先创立一个实体，并基于这个新创建的实体，再次新创建一个子实体。

V2 ODataModel 不反对在 同一个 API 申请里实现这个场景。

能够链接两个 API 调用来创立具备两个程序申请的父实体和子实体，如以下示例所示，该示例同时创立了一个销售订单和一个销售订单我的项目：

var oParentContext,
    oModel = this.getView().getModel();
 
oParentContext = oModel.createEntry("/SalesOrderSet");
oParentContext.created().then(function () {
  var oChildContext = oModel.createEntry("ToLineItems", {context : oParentContext});
 
  oModel.submitChanges(); // triggers request for creation of item});
 
oModel.submitChanges(); // triggers request for creation of sales order

ODataModel.createEntry 的一个局限性：

ODataListBinding.create 创立一个条目并将其插入到条目列表的结尾或结尾。该条目在绑定控件的对应地位可见，无需先保留到后端再刷新绑定；与 ODataModel#createEntry API 相比，这是一个劣势。

如果有一个 显示条目汇合 的列表或表格控件并且以下条件之一实用，请应用办法 ODataListBinding.create，而不是 ODataModel.createEntry：

• 创立的条目甚至在存储到后端之前就应该呈现在此表中，以便最终用户能够查看和批改他们的数据。
• 即便曾经长久化到后端，创立的条目也应该显示在表格中的雷同地位；只是他们的数据会依据创立 POST 申请的响应进行更新。
• 心愿提供内联创建行以疾速创立新条目。