Javascript 未在元数据中创建微风导航属性

我正在尝试将breeze.js与OData服务器（基于XPO）通信。在元数据中，存在来自服务器导航属性的xml，但它们不是为客户端类型的元数据创建的。我是做错了什么还是有bug

服务器元数据xml:

http://odataserver/Db.svc/$metadata

    <edmx:Edmx xmlns:edmx="http://schemas.microsoft.com/ado/2007/06/edmx" Version="1.0">
<edmx:DataServices xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" m:DataServiceVersion="3.0" m:MaxDataServiceVersion="3.0">
<Schema xmlns="http://schemas.microsoft.com/ado/2009/11/edm" Namespace="Namespace">
<EntityType Name="Question">
<Key>
<PropertyRef Name="Oid"/>
</Key>
<Property Name="Oid" Type="Edm.Int32" Nullable="false"/>
<Property Name="No" Type="Edm.String"/>
<Property Name="Header" Type="Edm.String"/>
<NavigationProperty Name="Chapter" Relationship="Namespace.Question_Chapter_Chapter_Questions" ToRole="Chapter_Questions" FromRole="Question_Chapter"/>
</EntityType>
<EntityType Name="Chapter">
<Key>
<PropertyRef Name="Oid"/>
</Key>
<Property Name="Oid" Type="Edm.Int32" Nullable="false"/>
<Property Name="No" Type="Edm.String"/>
<Property Name="Name" Type="Edm.String"/>
<NavigationProperty Name="Questions" Relationship="Namespace.Question_Chapter_Chapter_Questions" ToRole="Question_Chapter" FromRole="Chapter_Questions"/>
</EntityType>
<Association Name="Question_Chapter_Chapter_Questions">
<End Type="Namespace.Chapter" Role="Chapter_Questions" Multiplicity="0..1"/>
<End Type="Namespace.Question" Role="Question_Chapter" Multiplicity="*"/>
</Association>
<EntityContainer Name="DbService" m:IsDefaultEntityContainer="true">
<EntitySet Name="Question" EntityType="Namespace.Question"/>
<EntitySet Name="Chapter" EntityType="Namespace.Chapter"/>
<AssociationSet Name="Question_Chapter_Chapter" Association="Namespace.Question_Chapter_Chapter_Questions">
<End Role="Question_Chapter" EntitySet="Question"/>
<End Role="Chapter_Questions" EntitySet="Chapter"/>
</AssociationSet>
</EntityContainer>
<Annotations Target="Namespace.Chapter/No">
<ValueAnnotation Term="Org.OData.Validation.V1.Size" Int="100"/>
</Annotations>
<Annotations Target="Namespace.Chapter/Name">
<ValueAnnotation Term="Org.OData.Validation.V1.Size" Int="100"/>
</Annotations>
<Annotations Target="Namespace.Question/No">
<ValueAnnotation Term="Org.OData.Validation.V1.Size" Int="100"/>
</Annotations>
<Annotations Target="Namespace.Question/Header">
<ValueAnnotation Term="Org.OData.Validation.V1.Size" Int="100"/>
</Annotations>
</Schema>
</edmx:DataServices>
</edmx:Edmx>

---

将元数据加载到breeze后，结果在navigationProperties数组中有0项。

我通过调试breeze.js库发现了问题。Breezejs沉默着！如果未定义约束，则忽略导航属性。我认为它至少应该在javascript控制台上打印关于它的警告。我会提出催促要求。下面是breeze.debug.js中有问题的一行

  function parseCsdlNavProperty(entityType, csdlProperty, schema) {

   ...

    var constraint = association.referentialConstraint;
    if (!constraint) {
        // TODO: Revisit this later - right now we just ignore many-many and assocs with missing constraints.
        return;
        // Think about adding this back later.
        //if (association.end[0].multiplicity == "*" && association.end[1].multiplicity == "*") {
        //    // many to many relation
        //    ???
        //} else {
        //    throw new Error("Foreign Key Associations must be turned on for this model");
        //}
    }

 ...
}

由于未定义

约束

，方法将以静默方式返回并忽略导航属性。

---

我认为这个行为也应该在breeze.js文档中定义。

我同意，并将其添加到我们需要的文档增强列表中。但我也想指出，如果约束确实存在，而XPO忽略了它，那么这也是XPO的问题。为什么它们不生成约束？我们已经在其他OData提供者中看到了这一点，它们只实现了规范的一部分。我非常同意你的看法。我也在评估JayData和Microsoft实体框架OData的支持。让我分享我的发现。Jaydata忽略约束要求，生成导航行为时不会出现问题。此外，Microsoft ER OData层没有提供约束，尽管在第一个过程中存在关联。要求约束是正确的。事实上，大多数OData提供程序都存在约束问题，无法通过配置来修复这些问题，尤其是使用XPO OData提供程序时。我发现breeze的对象管理架构更好。所以（续）（续）（续）请记住，Breeze.js是OData服务的消费者，我认为它应该像JayData一样更宽容，并且生成导航属性时不受约束，假设它们应该是这样的。在这种情况下，它还应该向javascript控制台生成警告。作为一种解决方法，我将在Node.js中编写一个javascript文件生成器，其中包括像JayData jaysvcutil.exe这样的类型脚本定义，它将通过代码定义模式，并添加导航属性，而不考虑约束。当它结束时，我会分享它。我还是非常喜欢Breeze.js。

manager.metadataStore.getEntityType("Question")

  function parseCsdlNavProperty(entityType, csdlProperty, schema) {

   ...

    var constraint = association.referentialConstraint;
    if (!constraint) {
        // TODO: Revisit this later - right now we just ignore many-many and assocs with missing constraints.
        return;
        // Think about adding this back later.
        //if (association.end[0].multiplicity == "*" && association.end[1].multiplicity == "*") {
        //    // many to many relation
        //    ???
        //} else {
        //    throw new Error("Foreign Key Associations must be turned on for this model");
        //}
    }

 ...
}