未填充Breeze一对多单向导航属性 [英] Breeze 1-To-Many Unidirectional Navigation Property not Populated
问题描述
微风版本：1.5.3
Breeze Version: 1.5.3
我遇到了一些类似于SO上一些较早问题的东西，但似乎是 bug错误，经常发生：
I'm experiencing something similiar to some older questions on SO but it seems like this "bug" is reoccurring:
我有一个不填充的一对多单向导航属性。我已经检查了元数据和服务器的响应。我什至调试到微风，节点（或rawEntity）似乎也很完美。
I have a 1-To-Many unidirectional navigation property which is not populated. I have checked the metadata and the response from the server. I've even debugged into breeze and the node (or rawEntity) seems to be perfect.
我试图对其进行跟踪，并得出结论，它发生了，因为没有为我的导航属性找到了反向-属性，并且在不更新目标实体的情况下返回了mergeRelatedEntities-Function：
I've tried to track it down and came to the conclusion, that it happens, because no "inverse"-Property is found for my Navigation Property and the mergeRelatedEntities-Function returning without updating the target Entity:
function mergeRelatedEntities(mc, navigationProperty, targetEntity, rawEntity) {
var relatedEntities = mergeRelatedEntitiesCore(mc, rawEntity, navigationProperty);
if (relatedEntities == null) return;
var inverseProperty = navigationProperty.inverse;
if (!inverseProperty) return;
var originalRelatedEntities = targetEntity.getProperty(navigationProperty.name);
originalRelatedEntities.wasLoaded = true;
relatedEntities.forEach(function (relatedEntity) {
if (typeof relatedEntity === 'function') {
mc.deferredFns.push(function () {
relatedEntity = relatedEntity();
updateRelatedEntityInCollection(relatedEntity, originalRelatedEntities, targetEntity, inverseProperty);
});
} else {
updateRelatedEntityInCollection(relatedEntity, originalRelatedEntities, targetEntity, inverseProperty);
}
});
}
旧帖子：
和
好吧，我开始了解Ward对未映射属性的含义（通过查找两年前的类似问题：使用breezejs和Web API处理计算的属性）
Okay I start to understand what Ward meant with the unmapped properties (by finding a similar question from 2 years ago: Handling calculated properties with breezejs and web api)
我到目前为止：
function iUIConfigConstructorTool() {
this.ConfigToCurrentUSetting = null;
};
function iUIConfigConstructorAppl() {
this.ConfigToCurrentUSetting = null;
};
function iUIConfigConstructorWidget() {
this.ConfigToCurrentUSetting = null;
};
function iUIConfigInitializer(uiConfigObject) {
// initializing other properties
};
this.manager.metadataStore.registerEntityTypeCtor("Tool", iUIConfigConstructorTool, iUIConfigInitializer);
this.manager.metadataStore.registerEntityTypeCtor("Appl", iUIConfigConstructorAppl, iUIConfigInitializer);
this.manager.metadataStore.registerEntityTypeCtor("Widget", iUIConfigConstructorWidget, iUIConfigInitializer);
这就是我想要的。有没有办法从服务器？因为我在服务器上定义了计算的属性，并且元模型是由服务器提供的，所以如果添加新的Navigation-Property，我不想更改客户端实现。因此，我需要像元模型中的标志这样的东西来告诉微风，该属性需要通过导线填充而没有ForeignKeys等。
This does what I want. Is there a way, to do this over the metamodel from the server? Because I define my calculated properties on the server and the metamodel is delivered by the server, I don't want to change the client-side implementation if I add a new Navigation-Property. So I'd need something like a flag in the metamodel to tell breeze, that this property needs to be filled as it comes over the wire without ForeignKeys etc.
也许其他文字：我们正在执行子查询在服务器端（例如，找到具有订单但仅在特定日期之前的订单的客户），然后将其传递给微风（与客户的真实订单属性不同）。我们的问题是：因为元数据中没有直接连接，但是我们需要逻辑连接，所以我们如何解压缩该子查询。
Maybe in other words: We are doing "sub queries" on the server side (e.g. find Customers with it's Orders but only up to a certain Date) for each queried object and deliver this to breeze (in a separate property than the real orders-property of the Customer). Our problem is: How do we unpack this sub-query because there is no direct connection in metadata but we need the connection for the logic.
推荐答案
请使用以下内容更新您的问题：
Please update your question with:
-
如何获取/创建元数据
how you obtained/created metadata
两个端点的元数据（只是导航道具，pk道具和fk道具会做）
metadata for the two endpoints (just the nav props, pk prop, and fk props will do)
确切的查询表达式
当然，最欢迎使用plunker进行复制。
Of course a repro in plunker would be most welcome.
如果我正确理解您的评论，则有关问题的导航属性（由服务器提供）将由您维护，而不是
If I understand your comment correctly, the navigation property (properties) in question are to be maintained by you (w/ server-supplied info), not by Breeze.
这促使我建议您将其维护为 未映射 属性，而不是映射的导航属性。这有道理吗？
That leads me to suggest that you maintain them as unmapped properties rather than mapped, navigation properties. Does that make sense?
这篇关于未填充Breeze一对多单向导航属性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
