0

Breeze Version: 1.5.3

I'm experiencing something similiar to some older questions on SO but it seems like this "bug" is reoccurring:

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.

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);
        }
    });
}

Older Posts:

Non scalar navigation properties are not populating with "nodb" conception

and

Breeze (1.4.5) unidirectional one-to-many: navigation collection not populated

Edited 11. May 2015

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)

What I have so far:

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);

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.

Community
  • 1
  • 1
NoRyb
  • 1,472
  • 1
  • 14
  • 35

1 Answers1

0

Please update your question with:

  • how you obtained/created metadata

  • metadata for the two endpoints (just the nav props, pk prop, and fk props will do)

  • the exact query expression

Of course a repro in plunker would be most welcome.

update 7 May 2015

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?

Community
  • 1
  • 1
Ward
  • 17,793
  • 4
  • 37
  • 53
  • Thanks to your comment I read the "Metadata by hand (in depth)" carefully again. I'm missing the "invForeignKeyNames" (I create the metadata myself). The Problem is: It is a calculated association by the server, the entities are not "really" connected to eachother. It returns one UserSetting (the current one) of the many UserSettings in another Navigation Property called "UserSettings". It is filled by the QueryHelper (PostExecuteQuery). So my entity has two nav. properties: "UserSettings" and "CurrentUserSettings". – NoRyb May 07 '15 at 06:28
  • That makes sense. The property is maintained by the Server (we call them calculated properties) and is attached in PostExecuteQuery. Also this property contains real entities which can be merged into the cache manager and have real navigation properties. That's why I'd like breeze to treat them just like any other entity. Only the connection through the calculated property is something "special" and is only made by the server at query-execution. So how would I mark my navigation property in the metamodel as "unmapped"? I thought this is a client-feature... – NoRyb May 08 '15 at 08:20
  • I just edited my question with new insights. Would be helpful to have your comments on that. Thanks! – NoRyb May 11 '15 at 13:09