Opened 5 years ago

Closed 5 years ago

#17848 closed defect (patchwelcome)

Calling add in dijit/tree/ObjectStoreModel will cause Observable callback on all objects

Reported by: Wouter Hager Owned by: Kris Zyp
Priority: high Milestone: 1.10
Component: Data Version: 1.9.3
Keywords: Cc:
Blocked By: Blocking:


Adding a new object (store.add) in dijit/tree/ObjectStoreModel will cause Observable to notify a child is added *to each parentItem*, for which getChildren has previously been called.

When a child node is added to a tree, you can see that it is added in each loaded treenode with children.

Attachments (1)

0001-match-against-query-even-without-queryEngine.patch (1.7 KB) - added by Wouter Hager 5 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 5 years ago by bill

Component: GeneralData
Owner: set to Wouter Hager
Status: newpending

Sounds like a bug in Observable but you should try to come up with an isolated test case not involving Tree. At a minimum you need some kind of test case.

comment:2 Changed 5 years ago by Wouter Hager

Status: pendingnew

I know the exact problem. Because there's no query engine, the new item isn't matched to the query (i.e. getChildren). The only way to solve this is to add the match to Observable. See #17783

comment:3 Changed 5 years ago by Wouter Hager

Since each of the queries is observed, we need to specify to which query the new item actually applies, especially in case of a child item. Just using a query engine would mean paging and sorting would be overruled on the client, and I doubt we want that.

We're PUTting in relation to a parent, so perhaps this should be the starting point, instead of the query. Perhaps some relational store could be defined, with a relational observe method. This would be cleaner, since that is actually what is implemented. A hyperschema could inform the client of any relationships in the data. I really don't have any other ideas.

comment:4 Changed 5 years ago by Wouter Hager

I've added a patch for a naive solution, just matching against the query object. This means the requirement would be that the query is an object when no queryEngine is specified.

comment:5 Changed 5 years ago by dylan

Milestone: tbd1.10
Owner: changed from Wouter Hager to Kris Zyp
Priority: undecidedhigh
Status: newassigned

comment:6 Changed 5 years ago by Kris Zyp

I am not sure I understand exactly why the query engine can not be applied to the store, what is meant by paging and sorting being overruled? Obviously we would want to avoid duplicating the SimpleQueryEngine? code in Observable if possible.

comment:7 Changed 5 years ago by Wouter Hager

Agreed, it won't matter if the client re-applies paging and sorting. The only thing really lacking IMO was some example code of where this applies.

comment:8 Changed 5 years ago by Wouter Hager

Simply stating that query object equals relationships doesn't satisfy my needs. The implementation is too specific for "child item contains parent id", and doesn't take into account other kinds of relationships. This naive implementation will fail for any other solution, so it might as well be taken out.

That is way I was thinking of hyperschema. I don't see a simple solution to any complex relationships (e.g. $ref in jsonschema).

comment:9 Changed 5 years ago by Wouter Hager

Ok nevermind any of this. I'll provide my own query engine. This ticket may be closed.

comment:10 Changed 5 years ago by dylan

Resolution: patchwelcome
Status: assignedclosed
Note: See TracTickets for help on using tickets.