Opened 11 years ago

Closed 11 years ago

#7374 closed defect (fixed)

ClientFilter fetchItemByIdentity and JsonRestStore

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

JsonRestStore? uses fetch with q query of the id as the query for fetchItemByIdentity. If ClientFilter? is loaded, however, the cache is not searched, and fetchItemByIdentity seemsto not work.

I've modified cachingFetch to first look to see if args.query is a string, since this is the only way to "know" that its a pure identity call to fetch (unless perhaps we add an extra queryOption like "identityFetch" that fetchItemByIdentity uses?) If it is a string, it looks in all the cached results (not in Rest._index since ClientFilter? may be used in ServiceStore? or other stores without JsonRestStore?, so instead in any of the cachedArgs.cacheResults). If there is a hit, it creates a defResult with the result. If not, it sends it to the server via _doQuery.

Not sure if that is the "correct" solution, but it works.

Attachments (1)

ClientFilter.js.patch (2.3 KB) - added by maulin 11 years ago.

Download all attachments as: .zip

Change History (5)

Changed 11 years ago by maulin

Attachment: ClientFilter.js.patch added

comment:1 Changed 11 years ago by Kris Zyp

Owner: changed from Jared Jurkiewicz to Kris Zyp

Do you have a test case where fetchItemByIdentity fails in JsonRestStore?? With the ClientFilter? loaded, the cachedFetch misses but then JsonRest?.get is called and it goes to dojox.rpc.Rest._index and finds the object and seems to properly return it (without making a call to the server). If you are using ServiceStore? directly it uses it's own internal index which caches the identity of objects.

comment:2 Changed 11 years ago by maulin

You are right. Its that I was sending "/servicePath/1" as the id, so in 238 of JsonRest?, it was looking in the Rest._index under service.servicePath + id which would be "/servicePath/servicePath/1"

is it unreasonable to pass in the "whole" id to fetchItemByIdentity? Here is my dilemma:

I have a list of items that I want to filter based on the id of one of their associations:

items: [

{ id:"1", association:{$ref:"/association/1"} }, { id:"2", association:{$ref:"/association/1"} }, { id:"3", association:{$ref:"/association/2"} }

]

But I don't want to necessarily load the association yet.

So I want to do client side query like

itemsStore.fetch({query:{'association.id':"1"})

My store allows dot-path, so it essentially recursively calls getValue. But I don't want to have to load the association just to get the id, since it is right there in the $ref.

So I "partially populate" the associations: items: [

{ id:"1", association:{$ref:"/association/1", id:"1"} }, { id:"2", association:{$ref:"/association/1"}, id:"1" }, { id:"3", association:{$ref:"/association/2"}, id:"2" }

]

But that breaks things, because now json.ref thinks that the id in the association is referring back to items. Which leads me to write:

items: [

{ id:"1", association:{$ref:"/association/1", id:"/association/1"} }, { id:"2", association:{$ref:"/association/1"}, id:"/association/1" }, { id:"3", association:{$ref:"/association/2"}, id:"/association/2" }

]

And change my fetch to itemsStore.fetch({query:{'association.id':"1"})

which, at first glance, you would think could work, but JsonRest?.get calls

Rest._index+ 1? in this case, since I am using the itemsStore.

In all cases but fetchItemByIdentity, the service is figured out by parsing the identity and getting the service.

Anyway, this is clearly not a bug, but a flaw in my design of using the "wrong" store to access an item. But it works in all the other cases! I suppose I could check first if the id is prefixed or something, but I think I should probably just take a closer look at my design. Its the recursive getValue that is really the stem of the problem, since when it recurses it is now calling getValue for an item that is not *technically* managed by that store, but actually by a different store.

Ugh. I guess we close this ticket, since its not a bug. More of a forum issue on my design...

comment:3 Changed 11 years ago by Kris Zyp

I am not sure I understand the last issue. I follow how you ended up creating partially created objects like {$ref:"/association/1", id:"/association/1"}, that looks correct, but I don't understand how itemsStore.fetch({query:{'association.id':"1"}) causes a cache hit at Rest._index+ 1?. If you are using fetch, args.useIndexCache should be false and id should be an object (like 238 in JsonRest?.js).

comment:4 Changed 11 years ago by Kris Zyp

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.