Opened 11 years ago

Closed 11 years ago

#7179 closed defect (fixed)

JsonRestStore/ServiceStore clobbers sort, queryInfo when sending args to service method

Reported by: maulin Owned by: Kris Zyp
Priority: high Milestone: 1.2
Component: DojoX Data Version: 1.1.1
Keywords: Cc: kris@…
Blocked By: Blocking:

Description

In the _doQuery method (in both implementatons), it extracts the query from the fetch args and uses only this information when sending to the service get method (this.service(query) or dojox.rpc.JsonRest?.get(this.service, query) respectively).

But what if the server will be doing some sorting? Or what if it s relying on some queryInfo params? Can we change the call of service to:

service(id, optionalArgs) where optionalArgs is the original fetch request.

Rest can ignore it (though how will a Rest get of a query know the sort params?), but that way custom services can use all the info if needed (but can also ignore it for the simple cases)

Change History (4)

comment:1 Changed 11 years ago by Kris Zyp

Owner: changed from Jared Jurkiewicz to Kris Zyp

I will think about this, I am little nervous about breaking expectations of services that may have an optional second argument with a different meaning.

comment:2 Changed 11 years ago by maulin

I can obviously over-ride the _doQuery method in my subclass and then inform my service somehow of the other query args first. Or perhaps we add a store method to ServiceStore? called getFetchParams which gives you the raw fetch params. Then the service could call it to get the params it cares about. What I don't like about that is that it ties a service to a store tightly.

My current quick and dirty solution is:

note that Rest services put the start/end for count in the request header

_doQuery: function(args){

var id= typeof args.queryStr == 'string' ? args.queryStr : args.query; var service = this.service; if caching is allowed, we look in the cache for the result var cacheable = dojox.rpc.Rest._isCacheable();

var deferred, result = cacheable && dojox.rpc.Rest._index[(service.servicePath
) + id];

dojox.rpc.Rest._dontCache=0; reset it if(result && !result._loadObject){ cache hit

deferred = new dojo.Deferred(); deferred.callback(result); return deferred;

}

deferred = this.service(id, args); deferred.addCallback(function(result){

if(result.nodeType && result.cloneNode){

return immediately if it is an XML document return result;

} return dojox.json.ref.resolveJson(result, {

defaultId: cacheable ? id : undefined, FIXME: id should only not be omitted when ranges are used index: dojox.rpc.Rest._index, idPrefix: service.servicePath, idAttribute: dojox.rpc.JsonRest?.getIdAttribute(service), schemas: dojox.rpc.JsonRest?.schemas, loader: dojox.rpc.JsonRest?._loader

});

}); return deferred;

}

as you can see, because of the design, I can't make a simple call and then call this.inherited(). So. I m stuck having to rewrite JsonRest?.get.

Forgetting about queryInfo stuff, what was your plan for server-side sorting with JsonRestStore??

comment:3 Changed 11 years ago by Kris Zyp

I think this seems reasonable, we don't really have backwards compatibility to worry about, I will go ahead and make this change.

comment:4 Changed 11 years ago by Kris Zyp

Resolution: fixed
Status: newclosed

(In [14457]) Adds client side querying capabilities and result set updating per http://turtle.dojotoolkit.org/pipermail/dojo-interest/2008-July/032550.html, fixes #7172, fixes #7179, Refers #6981, Refers #7030, and updates to Offline Rest to utilize this (Refers #6815)

Note: See TracTickets for help on using tickets.