Preventing breeze.js from creating observables pro

问题:

I must be missing something simple, but can't figure it out. I'm retrieving a bunch of lookup tables in 1 Web API call.

return EntityQuery.from('Lookups')
       .noTracking(true)
       .using(manager).execute()
       .then(processLookups);

In processLookups I'm calling getLocal for each array that was returned. Example: State table

 datacontext.lookups = {
     state: getLocal('States', orderBy.state, true),
     ....
 }

function getLocal(resource, ordering, includeNullos) {

    var query = EntityQuery.from(resource)
        .orderBy(ordering)
        .noTracking(true);

    if (!includeNullos) {
        query = query.where('id', '!=', 0);
    }
    return manager.executeQueryLocally(query);
}

The arrays are not observable, but each property in the array objects are observable functions. This is just overhead I don't need since these will not be changing.

How can I prevent the object properties from being observable?

Thanks

回答1:

The raw lookups are available to you right there in the success callback from the query. No reason to look at cache ... even if they were there (which they are not as Jay makes clear).

But what would you DO with these lookups? Presumably you want them to be related (by Breeze navigation paths) to real entities. For example, you'd like session.room to return the related room object. But if the room is one of your lookups and is NOT an entity, then the session.room navigation property won't return it; nav properties always return entities.

I can think of ways around this. But it's just more work and more trickery.

Let's stop for a moment and ask the most important question: Why?

Why do you care if the lookups are entities with observable properties? It may be "overhead you don't need". But is it overhead that hurts you? Hurts you how? Have you measured it?

Forgive me but I sense premature optimizations that could be distracting you from more worthy pursuits. Happy to be proven wrong.

回答2:

I'm not sure I completely understand the situation but the 'noTracking' option is really only relevant with 'remote' queries. i.e. not local ones. Basically, 'noTracking' tells breeze not process the results of the query into breeze entities AND ALSO not to cache these results.

When you are querying the cache, which is what 'executeQueryLocally' is doing, both of these steps have already occurred, so 'noTracking' is ignored.