Changes between Version 16 and Version 17 of Ticket #16599

Jan 24, 2013, 4:29:16 PM (9 years ago)
Brian Arnold

Whoops, completely blew out the description by accident. Shouldn't update these when my mind is elsewhere. :) Fixed.


  • Ticket #16599 – Description

    v16 v17  
    1 I can appreciate what you're asking for, and understand its value to you, but the problem is that what you're asking for is a thing that very specifically meets your needs, and is not something that would make for a good general implementation.
     1I think it would be helpful that dojo/store provides an implementation of a query engine allowing (optionally) to recurse into the children of items, such that hierarchical data can be queried. This could be either an option of the default engine (store/util/SimpleQueryEngine) (say, similar to the deep:true option of dojo/data), or it could be implemented in a new, distinct engine.
    3 Implementing what you've described, basically taking SimpleQueryEngine and making it detect `getChildren` and iterate when a `deep` flag is set would honestly not be that hard to do, but it doesn't really meet any general needs. It meets yours.
     3As a bonus, it would be nice that dojo/store provides an in-memory store that implements the getChildren() method. (A related ticket:  #13781.)
    5 I really hope that doesn't sound like a jerk thing to say, but the need for a data structure that's truly hierarchical and not flattened is fairly uncommon, and queries against flattened structures are inherently deep. If a user doesn't want a deep query in that context, it's easy enough to query for items with a specific parent key (or lack thereof).
    7 The main problem with hierarchical data of this nature is that in order for a simple `get` to work, you'd still have to do a full traversal of the data in order to index all items by identifier, and this traversal would ideally happen at initialization. If your data is flat, you simply loop. If it's not, you have to recurse -- but you still wind up generating a flat representation of the data in the ideal case to simplify querying, and that starts to approach the weight (both LOC and memory) and proscriptive data structures that dojo/data requires.
    9 I would go so far as to argue that representating your data with deeper hierarchical structures is an antipattern, that doing a flattening is going to save time and effort for both the developer of the store and the user of the store. A reference store that demonstrates that approach would not be immensely difficult, but hierarchical data structures are distinct enough that it'd be difficult to create a generalized implementation. Parent-based keying is incredibly common and simple to implement in a general fashion without being proscriptive.
     5Adding such features would help people to replace the usage of the old dojo/data stores by dojo/store without loosing features and without forcing them to convert hierarchical data into flat data.