Opened 12 years ago

Closed 9 years ago

#10688 closed defect (wontfix)

JsonRestStore referential integrity problem on immediate deleteItem

Reported by: coa Owned by: Kris Zyp
Priority: high Milestone: tbd
Component: DojoX Data Version: 1.4.0
Keywords: JsonRestStore, PersevereStore Cc:
Blocked By: Blocking:


Refer to the supplied test case.

It seems that if the first action on the store is to DELETE a child item, that item will remain in the data store (listed in the parents children), even though it's deleted on the server.

This issue does not occur if the first action is to add a child item. Subsequent deletes works just fine.

N.B. test case assumes a simple server setup (easily changed)

Attachments (1)

RestTest.html (4.1 KB) - added by coa 12 years ago.

Download all attachments as: .zip

Change History (6)

Changed 12 years ago by coa

Attachment: RestTest.html added

comment:1 Changed 12 years ago by Jared Jurkiewicz

Owner: changed from Jared Jurkiewicz to Kris Zyp

comment:2 Changed 12 years ago by coa

Posting a converstion with kzyp for reference:

I made an observation today with JsonRestStore? that got me confused:

  • deleteItem doesn't seem to clean up all references properly:
    1. store.deleteItem(child);
    2. store.getValues(parent, "children") still contains child

On closer inspection of parent.children, I saw that it wasn't loaded yet, which would indicate that deleteItem indeed does it's job. It obviously couldn't delete a reference it wasn't aware of, and the DELETE hadn't been saved to the server yet.

So, why wasn't parent.children loaded? It amazed me, because it must have been loaded earlier - otherwise I wouldn't have the 'child' variable in the first place.

So, I tried this simple piece of code:

if (!store.isItemLoaded(parent.children)) {
	console.log("Children not loaded... loading them");
	dojox.rpc._sync = true;
if (!store.isItemLoaded(parent.children))
	console.warn("Children STILL NOT loaded!");

To my amazement it echoed "Children STILL NOT loaded!"

loadItem doesn't seem to update dojox.rpc.Rest._index, which I assume it has to do if deleteItem should be able to clean up the (client-side) references?

I'm truly confused, shouldn't loadItem update _index? And if it shouldn't, then what's the point with deleteItem's hunt for dead references?

comment:3 Changed 12 years ago by coa


I know that part of the issue here is that the lazy reference object returned from parent.children can't be mutated into an object (you can change an object into an array in JS), so loadItem should return the loaded array, but the old lazy reference object will still act as not being loaded. I am not sure if that is the entirety of the problem though.

comment:4 Changed 12 years ago by coa


Ahh - that's got to be it! In fact, that must also be the answer to the problem I had a few weeks ago, (

If mutating the object can't be done, why not just overwrite it - conceptually: In ServiceStore?.getValues(), if value is a lazy array, load it and:

dojox.rpc.JsonRest._saveNotNeeded = true;
this.setValues(item, property, value);
dojox.rpc.JsonRest._saveNotNeeded = false;

This fixes #10688, but seems almost to easy...

Unfortunately, deleteItem still leaves dead references. It splices the array correctly, but never reaches line 212:

( || store).setValue(parent, i, value.__checked);

Is the conditional before really correct? As far as I can tell, value.__checked will always be undefined after splicing. Also, what's the point in returning the spliced array, if it's never used by the caller?

comment:5 Changed 9 years ago by Colin Snover

Resolution: wontfix
Status: newclosed

dojox/data is abandoned. Some dojox/data stores have been upgraded to use the Dojo Store API and can be found at

Note: See TracTickets for help on using tickets.