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

[Wouter Hager]

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.

[bill]

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.

[Wouter Hager]

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

[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.

[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.

[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.

[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.

[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).

[Wouter Hager]

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