JsonRest eager fetch

[maulin]

I define "eager fetch" as first loading a core set of properties, upon completing load, then a second set of more detailed properties are fetched ASYNC. The idea is that I want to use the time that a user is looking at the primary display to load detail in the background. Its an optimization on lazy fetch, such that if the user clicks (for example) to get detail on an object, they won't necessarily have to wait for a lazy load, if the eager fetch has already returned. The reason I wouldn't load an eager property in the initial load, isto provide the user a quick overview of the data, in a view that does not require the full data.

Its pretty simple to implement: If you have a schema property with an attribute called eager=true, then this property will begin to load async once the object is loaded.

Here is the code. I don't think this is necessarily core functionality. Perhaps its mixin type functionality. (For example, if you include dojox.data.EagerFetch? then you get this behavior)

(function() {

var originalGet = dojox.rpc.JsonRest?.get; add a callback that handles eager loading of eager properties dojox.rpc.JsonRest?.get = function(service, id, args) {

var d = originalGet.apply(this, arguments); d.addCallback(function(result) {

var arr = result; if (!(arr instanceof Array)) {

arr = [result];

} dojo.forEach(arr, function(item) {

if any eager properties, then start loading them asynchronously var store = dojox.data._getStoreForItem(item); if (store && store.schema && store.schema.properties) {

var props = store.schema.properties; console.debug("found props", props); for (var propName in props) {

var prop = props[propName]; if (prop.eager) {

console.debug("found eager prop", prop, item[propName]); if (item[propName] && item[propName]._loadObject) {

console.debug("initiating eager fetch: ", item, prop); item[propName]._loadObject(function(eagerlyLoadedItem) {

console.debug("eagerly loaded. should i add a publish event here?", eagerlyLoadedItem);

});

}

}

}

}

}); return result;

}); return d;

}

})();

[Kris Zyp]

It seems like this would generate a lot of requests. A result set with a 100 items and two eager properties per object would create 200 requests, and I think this would slow down the responsiveness of the browser. Wouldn't be faster to do your initial fast query to satisfy the UI, and then afterwards to the slower async loading by sending a query with a special parameter in the query that would go to the server indicating that it should send down a fuller result set? This would result in a single request and the server could determine what to send on each request (the small and the bigger one).

[maulin]

i agree, but there are edge cases where this may be useful. Ihave one specific one in mind, where I have a small data set (10 items), and each requires a rather intensive call to an external service to get the "detail". But I like the idea of an eager load of a SET of eager props. But I can't think (right now) of an API to handle this. I'll mull it over...

[ben hockey]

is this something we need to continue to track?

if there's no response within 14 days it will close automatically

[trac-o-bot]

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!