Opened 8 years ago

Last modified 6 years ago

#17783 assigned defect

dojo/store/JsonRest + Observable: add/put new item not observed

Reported by: Wouter Hager Owned by: dylan
Priority: undecided Milestone: 1.15
Component: Data Version: 1.9.3
Keywords: Cc:
Blocked By: Blocking:


Both removedFrom and insertedInto are -1 in Observable line 120, callback is ignored.

Simple test added (adapted from dijit/tree/ObjectStoreModel).

Attachments (1)

test_observable_jsonrest.html (3.3 KB) - added by Wouter Hager 8 years ago.
testing JsonRest?+Observable

Download all attachments as: .zip

Change History (18)

Changed 8 years ago by Wouter Hager

testing JsonRest?+Observable

comment:1 Changed 8 years ago by Wouter Hager

I've updated the test to reflect the difference between Memory and JsonRest? observed. This is taken from the store-driven tree example:

comment:2 Changed 8 years ago by Wouter Hager

I just found out the if I replace "put" with "add" in the example, the result is indeed monitored. Cost me some hours... Please update the example:

comment:3 Changed 8 years ago by Wouter Hager

Nevermind that. I was trying to isolate a bug for dijit/tree/ObjectStoreModel, but when I use store.add() all parentItems are notified... I really don't understand how this is supposed to work.

comment:4 Changed 8 years ago by bill

Component: GeneralData
Owner: set to Kris Zyp

comment:5 Changed 8 years ago by bill

#17844 is a duplicate of this ticket.

comment:6 Changed 8 years ago by bill

#15336 is a duplicate of this ticket.

comment:7 Changed 8 years ago by Wouter Hager

So as I now understand it, my previous comment was indeed correct. The store's add method will be monitored, as (presumably without a query engine) Observable will simply consider put an update. The existingId is explicitly passed, no matter if the object didn't exist before. The API is quite shady, especially concerning the use of a queryEngine.

So, they way Observable does observe new data is either by using add or with a queryEngine (e.g. SimpleQueryEngine?).

I can imagine a third way should be in case the data has no id, relying on the server to generate a key. This is in line with W3C object store spec. This would require something in the line of:

// in whenFinished, send along original value
when(results, function(results){
    action((typeof results == "object" && results) || value,value);
// find id in original object (if it wasn't there, existingId will be undefined)
whenFinished("put", function(object,original){
    store.notify(object, store.getIdentity(original));
Last edited 8 years ago by Wouter Hager (previous) (diff)

comment:8 Changed 8 years ago by Wouter Hager

To be complete, I would be willing to provide a tutorial to create a store-driven Tree with JsonRest? and Persevere (Kris should be so happy)...

comment:9 Changed 8 years ago by bill

That would surely make a lot of people happy, and you can do it at

comment:10 Changed 8 years ago by Kris Zyp <[email protected]…>

In dd9512b09e1a79fb83de7fa1d8bd52038d7fd368/dojo:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:11 Changed 8 years ago by Kris Zyp

Yes, I would certainly be very happy to see a tutorial!

I adjusted the suggested patch slightly, in case the original object was modified. And to be clear, the main issue that needs to be addressed is when a put operation results in a new object, and then the notification needs to properly reflect this, right? Let us know if this addresses this.

comment:12 Changed 8 years ago by Wouter Hager

This should work, yes. Please note, however, that the callback still differs from that of the queryExecutor (see #17848).

comment:13 Changed 8 years ago by Wouter Hager

This probably means Observe will never correctly work without a queryEngine, because the queryObject is never matched against the new object. Please update the reference to warn about this requirement, or simply add the dependency (at least the matching part).

comment:14 Changed 7 years ago by dylan

Milestone: tbd1.12
Owner: changed from Kris Zyp to dylan
Status: newassigned

So what remains is mostly a documentation fix then?

comment:15 Changed 7 years ago by Wouter Hager


I put my work on Persevere-based modelling on hold, but might resume it next year. However, it will probably be a completely different back-end.

comment:16 Changed 7 years ago by Wouter Hager

Another option would be to auto-include a QueryEngine? when resolving Observe.

comment:17 Changed 6 years ago by dylan

Milestone: 1.131.15

Ticket planning... move current 1.13 tickets out to 1.15 to make it easier to move tickets into the 1.13 milestone.

Note: See TracTickets for help on using tickets.