breeze.js not honoring the "noTracking" option when end point returns multiple result sets - api

Question

Consider this breze query:
return EntityQuery.from('myAPI')
.noTracking(true)
.using(manager).execute()
.then(querySucceeded)
.fail(queryFailed);
My API is defined like this:
[HttpGet]
public object myAPI()
{
// var userId = get the users id from auth ticket
var userPref = _contextProvider.Context.UserPreferences.Where(u => u.userId == userId);
var userOptions = _contextProvider.Context.UserOptions.Where(u => u.userId == userId);
return new
{
userPref,
userOptions
};
}
I know I can get access to the raw data, which is great. But in addition to this, the entities are created in the entity manager, which I would prefer they not be. This works fine for apis that return IQueryable. Is there a different syntax for noTracking for web apis that returns multiple result sets?
thanks

Answer 1

I can't reproduce the error you describe. I have a similar DocCode test that passes which references Breeze v1.5.3.
Here is the pertinent NorthwindController method:
[HttpGet]
public object Lookups()
{
var regions = _repository.Regions;
var territories = _repository.Territories;
var categories = _repository.Categories;
var lookups = new { regions, territories, categories };
return lookups;
}
And here's the passing QUnit test:
asyncTest('object query (e.g., lookups) w/ "no tracking" does not add to cache', function () {
expect(2);
var em = newNorthwindEm();
EntityQuery.from('Lookups')
.noTracking(true)
.using(em).execute()
.then(success).fail(handleFail).fin(start);
function success(data) {
var lookups = data.results[0];
var hasLookups = lookups &&
lookups.categories && lookups.regions && lookups.territories;
ok(hasLookups, 'Expected a lookups object w/ categories, regions and territories');
var cached = em.getEntities();
var len = cached.length;
equal(0, len, 'Expected ZERO cached entities of any kind and got ' + len);
}
});
If I comment out the noTracking(true) clause, the test fails and tells me that there are 65 entities in cache ... as predicted.
What am I missing?