Opened 13 years ago
Closed 9 years ago
#7261 closed enhancement (invalid)
JsonRest eager fetch
Reported by: | maulin | Owned by: | maulin |
---|---|---|---|
Priority: | low | Milestone: | future |
Component: | DojoX Data | Version: | 1.1.1 |
Keywords: | Cc: | [email protected]… | |
Blocked By: | Blocking: |
Description
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;
}
})();
Attachments (1)
Change History (6)
Changed 13 years ago by
Attachment: | EagerFetch.js added |
---|
comment:1 Changed 13 years ago by
Owner: | changed from Jared Jurkiewicz to Kris Zyp |
---|
comment:2 Changed 13 years ago by
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...
comment:3 Changed 13 years ago by
Milestone: | 1.2 → future |
---|
comment:4 Changed 9 years ago by
Owner: | changed from Kris Zyp to maulin |
---|---|
Status: | new → pending |
is this something we need to continue to track?
if there's no response within 14 days it will close automatically
comment:5 Changed 9 years ago by
Resolution: | → invalid |
---|---|
Status: | pending → closed |
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!
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).