breeze: unidirectional one-to-many navigation with compound foreign key still not populating in spite of invForeignKeyNames being defined

Question

I am currently using Breeze 1.5.3.

I have defined the metadata for my model so that there is a unidirectional one-to-many relationship between two entities Column -> ColumnStatistic.

When I inspect the JSON returned by my service I see a ColumnStatistics collection for each Column, but this collection is empty when I inspect the resulting entities.

I'm using EF6 to provide the primary and foreign key information. The relevant statements in my OnModelCreating method are the following ones.

modelBuilder.Entity<Column>().HasKey(c => new { c.Owner, c.TableName,  c.ColumnName});
modelBuilder.Entity<ColumnStatistic>().HasKey(s=> new { s.Owner, s.TableName, s.ColumnName, s.StatisticName });
modelBuilder.Entity<Column>().HasMany(c => c.ColumnStatistics).WithRequired().HasForeignKey(s => new { s.Owner, s.TableName, s.ColumnName });

I've created a plunker for this example. The example is a little more complicated than it needs to be since it contains metadata for entities outside the scope of this writeup, but I clearly see the Column_ColumnStatistics relationship in my metadata along with the associated foreign key constraint.

"association": [{
        "name": "Column_ColumnStatistics",
        "end": [{
            "role": "Column_ColumnStatistics_Source",
            "type": "Edm.Self.Column",
            "multiplicity": "1",
            "onDelete": {"action": "Cascade"}
        },
        {
            "role": "Column_ColumnStatistics_Target",
            "type": "Edm.Self.ColumnStatistic",
            "multiplicity": "*"
        }],
        "referentialConstraint": {
            "principal": {
                "role": "Column_ColumnStatistics_Source",
                "propertyRef": [{"name": "Owner"},
                                {"name": "TableName"},
                                {"name": "ColumnName"}]
            },
            "dependent": {
                "role": "Column_ColumnStatistics_Target",
                "propertyRef": [{"name": "Owner"},
                                {"name": "TableName"},
                                {"name": "ColumnName"}]
            }
        }
    }

All foreign key fields appear in the instances of ColumnStatistic returned by my service. A typical example of this data is the following.

{
"$id": "1",
"$type": "Archive.DtoModels.OracleMetadata.Column, Archive",
"Owner": "FUSION",
"TableName": "SGP_STUDENT",
"ColumnName": "CONSOLIDATED_SUBGROUP_CURR",
"DataType": "VARCHAR2",
"ColumnStatistics": [{
    "$id": "2",
    "$type": "Archive.DtoModels.OracleMetadata.ColumnStatistic, Archive",
    "Owner": "FUSION",
    "TableName": "SGP_STUDENT",
    "ColumnName": "CONSOLIDATED_SUBGROUP_CURR",
    "StatisticName": "HasNull",
    "StatisticValue": 0},...]
}  

Also, when I inspect the ColumnStatistics property of the Column entity type in my metadataStore I see that invForeignKeyNames is correctly defined as the three value composite key that I specify in the metadata. By design inverse is undefined because I intend this to be a unidirectional navigation property from the one side to the many side only.

Based on my reading of the Breeze release notes, the definedness of invForeignKeyNames should be sufficient to guarantee 1 to n navigability in versions >= 1.3.5. Since invForeignKeyNames is defined in my case, the situation appears to be different than that outlined in the post closest to mine that I managed to uncover on this site. Without having yet delved into the breeze source code, I am wondering if the composite keys in my example are part of the problem?

Answer 1

Sorry but breeze does not support navigation with composite foreign keys.

The primary key can be a composite key. A navigation property can be linked to one of the properties of that composite key. But the FK itself can only be one property.

Clearly we contemplated this possibility by defining the foreignKeys and invForeignKeys properties as arrays. But we delayed implementation (which adds much complexity) until we saw significant demand. In 14 years of tracking this possibility, you are perhaps the first (at least among the few) to have run into it.

You can post a request for this feature on our user voice. But you will need another approach for now.

Do you have a lot of these kind of properties in your model? Is it read-only? If it is fairly isolated you may be able to workaround it by transforming the three-part key into a single part key with client-side manipulation in a JsonResultsAdapter. If this idea is remotely appealing, we can work it out together in a follow-up.