Opened 11 years ago

Closed 11 years ago

#7257 closed enhancement (wontfix)

JsonRestStore support for lazy properties/sparsely populated objects

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

Description

I am trying to figure out how to use JsonRestStore? to lazily individual properties of an object. My plan was as follows -- the server would return the following on a request of id = 1

{

"id":"1", "foo":"fooValue", "bar":{"$ref":"1.bar"}

}

when you call store.getValue(item, "bar")

a request is made for "1.bar" which returns

{

"id":"1", "bar":"The lazily loaded value for bar"

}

JsonRestStore? handles this well via dojox.json.ref except that because this second returned object does not have the value for "foo" set, it deletes foo [lines 133-143 or ref.js]. I could see how this would be a reasonable thing to do in many circumstance (i.e. when an object is re-loaded, the object value is now the newly returned instance), however, in my case this is bad.

My proposed solution is that you can provide some metadata in the schema to tell ref how to handle loading an object with the same id (an update). So if I provide a schema with the following:

{

properties:{}, prototype:{}, sparse:true

}

or something like that, then it will not do this deletion (i.e. it will allow loading of sparse objects that taken together mash up to a completed object).

whaddya think? Any other way of implementing lazy-property behavior you can think of?

Attachments (1)

ref.js.patch (918 bytes) - added by maulin 11 years ago.

Download all attachments as: .zip

Change History (5)

Changed 11 years ago by maulin

Attachment: ref.js.patch added

comment:1 Changed 11 years ago by maulin

(By the way, I understand that if simply return a string for the call to load "1.bar" then bar would get loaded as the string. But this is a more broad scenario where I may actually have two versions of an object -- a sparse object and a complete object, so I may actually load more than one value on my call to 1.bar.

comment:2 Changed 11 years ago by Kris Zyp

Owner: changed from Jared Jurkiewicz to Kris Zyp

So my strategy for the sparse and complete object scenario was that you would probably load sparse objects as items in a result set: [

{

"$ref":"1", "foo":"fooValue"

}

] This would indicate to the Dojo JsonRestStore? that this object is not loaded, but it would still have the provided properties available. Then when you try to access a property that is not available on that object, JsonRestStore? will load the complete object by request "1" and then the remaining properties would become available. Users could also use loadItem to load the object. A request to "1" could return: {

id:"1", foo:"fooValue", bar:"barValue", baz:"bazValue"

}

The advantage of this is the you don't even need to include the unloaded property names in the sparse objects, which would allow you to keep result sets as light as possible (this is usually where you have the biggest overhead). Then requests directly for an object consistently always return a complete object. Since this is a request for a single object, a complete object is usually not very heavy (as opposed to a result set).

Does this seem like a reasonable approach, or do you still think you need to do sparse + sparse object additions? I am little concerned about that approach being rather complicated, both for client code and others who might try to implement it on the server.

comment:3 Changed 11 years ago by maulin

ooh. I like your approach much better. It didn't even occur to me. This would be a great blog post to describe all the techniques of JsonRestStore? laziness... thanks.

comment:4 Changed 11 years ago by Kris Zyp

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