Entity manager cache not working

**Model**

Perhaps you are wondering 
(a) Why did the query return results but no entities in cache? 

(b) Why did Breeze allow the model type and DbContext namespaces to be mismatched? Why didn't it protest?
Let me assure you that Breeze behaved exactly as intended ... if not in the way you expected.

In this example, the client query was routed to the Web API controller's "Items" method. The server responded with JSON data for a type 'Item" belonging to the namespace 'Model'.  Breeze on the client doesn't know about an 'Item' type in the namespace 'Model'; it knows about an 'Item' type in the namespace 'Data'. But that's not the same type at all. Breeze simply doesn't know what type of data it received. Therefore, it cannot turn that data into 'Item' entities ... which is why there are no Items in cache.

But the server did return data and Breeze dutifully provides those data as JavaScript objects in the 'data.results' array of the query promise. In the post which started this thread, we know the server returned 45 'somethings'. They weren't entities - Breeze didn't know what they were. But you, the developer, asked for them and here they are.

Breeze does not demand that a query return entities. If the service returns data that it recognizes as entities - if the data are identified in metadata as entity types  - Breeze will turn those data into entities and will put them in cache. Otherwise it forwards them to the caller via the promise.

There is nothing wrong with the server sending arbitrary data to the client. That's actually a useful feature.  For example, suppose you have a Person entity and Person has 100 columns/properties including an image property that could be 100KB. We want to present a list of Persons, just their first and last names. We can't afford to download every property of every Person in the list. 

Well, in Breeze we can make a "projection query" - a query for selected properties - and transmit only the properties we need. Clearly the data objects that satisfy our query are not whole Person entities. They are something else, something unnamed and un-typed. But something useful nonetheless.

Breeze doesn't judge. It doesn't insist that the query return whole Person entities. It simply examines the incoming data. If they are Persons, they become entities in cache. If not, fine, pass them along to the caller.

Therefore, Breeze shouldn't protest when it receives a data object of an unrecognized type. It was prepared to recognize 'Data.Item' data; it received 'Model.Item" data; no big deal ... and no entities in cache either.

---

This isn't the entire story. Actually, Breeze examines the incoming data objects looking for entities. If the incoming data are object graphs,  Breeze traverses the graphs, looking for objects which it recognizes as entities. If it finds entities within the object graphs, it puts them in cache.

This is a super valuable feature. I use it to query and cache all of my pick-lists in a single shot. For example, I might create a service method called "Lookups" that returns a single object whose properties are arrays of Color, Status, Size, ProductType, ... you get the idea. That object is essentially a bag of lists that I'll use to populate comboboxes.

Then I make a single query to "Lookups" ... which returns this bag of lists. Now breeze doesn't recognize the bag at all. But each of the bag's properties is a a collection of objects that are described in metadata: Color is an entity type, Status is a type, Size is a type, ProductType is a type. Breeze recognizes that these nested objects are entities and puts them in cache. 

So in a single request, in a single payload, I'm able to populate the EntityManager cache with all of the little pick-lists.

That's pretty cool.

Edited by WardBell - 07-Nov-2012 at 8:29pm