Adding Navigation property breaks breeze client-side mappings (but not Server Side EF6)

Question

I have an application that I developed standalone and now am trying to integrate into a much larger model. Currently, on the server side, there are 11 tables and an average of three navigation properties per table. This is working well and stable.

The larger model has 55 entities and 180+ relationships and includes most of my model (less the relationships to tables in the larger model). Once integrated, a very strange thing happens: the server sends the same data, the same number of entities are returned, but the exportEntities function returns a string of about 150KB (rather than the 1.48 MB it was returning before) and all queries show a tenth of the data they were showing before.

I followed the troubleshooting information on the Breeze website. I looked through the Breeze metadata and the entities and relationships seem defined correctly. I looked at the data that was returned and 9 out of ten entities did not appear as an object, but as a function: function (){return e.refMap[t]} which, when I expand it, has an 'arguments' property: Exception: TypeError: 'caller', 'callee', and 'arguments' properties may not be accessed on strict mode functions or the arguments objects for calls to them.

For reference, here are the two entities involved in the breaking change.

The Repayments Entity

public class Repayment
{
    [Key, Column(Order = 0)]
    public int DistrictId { get; set; }

    [Key, Column(Order = 1)]
    public int RepaymentId { get; set; }

    public int ClientId { get; set; }

    public int SeasonId { get; set; }

     ...

    #region Navigation Properties

    [InverseProperty("Repayments")]
    [ForeignKey("DistrictId")]
    public virtual District District { get; set; }


    // The three lines below are the lines I added to break the results
    //  If I remove them again, the results are correct again
    [InverseProperty("Repayments")]
    [ForeignKey("DistrictId,ClientId")]
    public virtual Client Client { get; set; }

    [InverseProperty("Repayments")]
    [ForeignKey("DistrictId,SeasonId,ClientId")]
    public virtual SeasonClient SeasonClient { get; set; }

The Client Entity

public class Client : IClient
{
    [Key, Column(Order = 0)]
    public int DistrictId { get; set; }

    [Key, Column(Order = 1)]
    public int ClientId { get; set; }

    ....

    // This Line lines were in the original (working) model
    [InverseProperty("Client")]
    public virtual ICollection<Repayment> Repayments { get; set; }

    ....
}

The relationship that I restored was simply the inverse of a relationship that was already there, which is one of the really weird things about it. I'm sure I'm doing something terribly wrong, but I'm not even sure at this point what information might be helpful in debugging this.

For defining foreign keys and inverse properties, I assume I must use either data annotations or the FluentAPI even if the tables follow all the EF conventions. Is either one better than the other? Is it necessary to consistently choose one approach and stay with it? Does the error above provide any insight as to what I might be doing wrong? Is there any other information I could post that might be helpful?

Breeze is an excellent framework and has the potential to really increase our reach providing assistance to small farmers in rural East Africa, and I'd love to get this prototype working.

THanks

Jay Traband Jay Traband · Accepted Answer · 2015-01-12T20:47:14

Ok, some of what you are describing can be explained by breeze's default behavior of compressing the payload of any query results that return multiple instances of the same entity. If you are using something like the default 'json.net' assembly for serialization, then each entity is sent with an extra '$id' property and if the same entity is seen again it gets serialized via a simple '$ref' property with the value of the previously mentioned '$id'.

On the breeze client during deserialization these '$refs' get resolved back into full entities. However, because the order in which deserialization is performed may not be the same as the order that serialization might have been performed, breeze internally creates deferred closure functions ( with no arguments) that allow for the deferred resolution of the compressed results regardless of the order of serialization. This is the

function (){return e.refMap[t]}

that you are seeing.

If you are seeing this value as part of the actual top level query result, then we have a bug, but if you are seeing this value while debugging the results returned from your server, before they have been returned to the calling function, then this is completely expected ( especially if you are viewing the contents of the closure before it should be executed.)

So a couple of questions and suggestions

Are you are actually seeing an error processing the result of your query or are simply surprised that the results are so small? If it's just a size issue, check and see if you can identify data that should have been sent to the client and is missing. It is possible that the reference compression is simply very effective in your case.
take a look at the 'raw' data returned from your web service. It should look something like this, with '$id' and '$ref' properties.
```
[{
  '$id': '1',
  'Name': 'James',
  'BirthDate': '1983-03-08T00:00Z',
 },
 {
  '$ref': '1'
}]
```
if so, then look at the data and make sure that an '$'id' exists that correspond to each of your '$refs'. If not, something is wrong with your server side serialization code. If the data does not look like this, then please post back with a small example of what the 'raw' data does look like.

Adding Navigation property breaks breeze client-side mappings (but not Server Side EF6)

2 Answers