Opened 7 years ago
Closed 7 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: |
Description
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)
Change History (11)
comment:1 Changed 7 years ago by
Component: | General → Data |
---|---|
Owner: | set to Wouter Hager |
Status: | new → pending |
comment:2 Changed 7 years ago by
Status: | pending → new |
---|
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 7 years ago by
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.
Changed 7 years ago by
Attachment: | 0001-match-against-query-even-without-queryEngine.patch added |
---|
comment:4 Changed 7 years ago by
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 7 years ago by
Milestone: | tbd → 1.10 |
---|---|
Owner: | changed from Wouter Hager to Kris Zyp |
Priority: | undecided → high |
Status: | new → assigned |
comment:6 Changed 7 years ago by
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 7 years ago by
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 7 years ago by
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 7 years ago by
Ok nevermind any of this. I'll provide my own query engine. This ticket may be closed.
comment:10 Changed 7 years ago by
Resolution: | → patchwelcome |
---|---|
Status: | assigned → closed |
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.