Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#5735 closed enhancement (wontfix)

ItemFileReadStore: Add complex query capability [patch] [CLA]

Reported by: Frank Fortson Owned by: Jared Jurkiewicz
Priority: high Milestone:
Component: Data Version: 1.0
Keywords: ItemFileReadStore complex query Cc: frank.fortson@…
Blocked By: Blocking:


There have been forum requests for a complex query capability against data stores vs. the current AND-only queries. The attached patch implements complex query for ItemFileReadStore?, which is inherited by ItemFileWriteStore?, and perhaps other stores.

Whereas, the current query is of the form:


the new query is of the form:

query:"id:'a*' AND type:'new' or (class:'in-use' && !testResults:false)"
The supported logical operators (case insensitive) are: , AND OR NOT ! &&
( ).

Legacy syntax is supported.

A test file is attached, which should be placed in the dojox/grid/tests directory. You can try out various queries in the input box and see the results in the Grid.

The only anomaly noticed is the markup parser (or ??) apparently assumes that a markup query points to a json object and calls dojo.fromJson(). Currently, that function returns the passed json (good), with the only penalty being a console message "Syntax error...". There is, however, Ticket 5725 that would throw an exception. I could use help finding and correcting the markup (or ??) parsing call to dojo.fromJson().

Note: The attached patch's (my first) first few lines should probably not be there??

Attachments (2)

test_dojo_data_complexquery.html (6.7 KB) - added by Frank Fortson 11 years ago.
Store complex query test file--place in dojox/grid/tests
ItemFileReadStore-complexQuery.patch (7.1 KB) - added by Frank Fortson 11 years ago.
ItemFileReadStore? complex query patch

Download all attachments as: .zip

Change History (10)

Changed 11 years ago by Frank Fortson

Store complex query test file--place in dojox/grid/tests

Changed 11 years ago by Frank Fortson

ItemFileReadStore? complex query patch

comment:1 Changed 11 years ago by Adam Peller

Frank, iiuc, the query attribute is defined to be an Object, so the parser expects JSON. I don't think the parser infrastructure can handle multiple types per attribute. Might it be possible to encode this as an object somehow?

comment:2 Changed 11 years ago by Frank Fortson

My original implementation did that, e.g.,


but I realized that is a bit convoluted for a user. I could go back and do that...

A problem with the above is that queries could be constructed where the various symbols used for quotes, e.g., "", ', would be exhausted, e.g.,

query="{complexQuery:'id:"3*" and test:"yes"'}"

which might be a burden on the user, if it would even work...

One reason I rewrote it to more natural language (and it works fine in programmatic and markup, just that one non-failing syntax console message for markup only) is my read of the docs for the data store api's is that there are no assumptions as to the form of the query that is passed, that it could be an object or string, for complex queries, which makes sense.

If we can find the part of markup parsing that calls dojo.fromJson() and change it to try it, if it fails, then pass it on anyway (without the error message), all should be well.

That said, I'll change it back to an object, if you feel that is best.

Alternatively, if the parser will only support one type for query, I suppose the type could be changed to string, but might be a problem for legacy, where the patch would still support the legacy in markup (since it uses a quoted object), but not in programmatic (where legacy is a pure object).

The patch, as submitted supports all cases (I believe), legacy and not, except for the non-failing syntax message to console.

comment:3 Changed 11 years ago by Adam Peller

another more natural option might be to have a separate parameter for complexQuery=<string>

Whatever the solution, markup attribute types must be static, according to current dojo/dijit design, if I'm not mistaken. I think trying to catch the json exception would add complexity and break this model (and I do think we're heading in the direction of doing a throw there)

comment:4 Changed 11 years ago by Frank Fortson

Good suggestion. Not sure what would be involved in adding an attribute-may be easy??

I'm not wedded to the patch above, just would like to see (actually, need) a complex query capability, in my case, at the moment, for the Grid. Thanks for considering it.

comment:5 Changed 11 years ago by bill

Also, not sure this should even be part of ItemFileReadStore?. That store is not meant to be the end-all for everything. Maybe you should be making a new store perhaps extending ItemFileReadStore?. I guess it amounts to the same thing though.

Note also that Dustin is/already has checked in a store based on xpath and that may support and/or queries. Not sure.

comment:6 Changed 11 years ago by Frank Fortson

My need is for a write store with a complex query. ItemFileWriteStore? inherits its "fetch" from ItemFileReadStore?. You are right, in that I was selecting a basic store that has been highlighted and used in examples in the dojo site. There could well be a better store to use.

For my use, I could have just subclassed or extended a store. The reasons I sought some guidance here, by posting the ticket, are:

  1. a query that can only query on one column, or multiple columns with AND as the only operator limits dynamic user filtering of data, and thereby effective use of the store.
  1. I've seen the request multiple times for complex queries (I might be proven wrong, if someone does a Search...), and have helped people off-line that decided to do remove/add data rows dynamically to support user filtering, due to the lack of a complex query capability.

So, you've raised the right question: Should the basic data stores, i.e., ItemFile?Store, support complex queries? Maybe not--I'm pretty new here.

I appreciate the good ideas here for alternatives. I'll explore those.

comment:7 Changed 11 years ago by Frank Fortson

Resolution: wontfix
Status: newclosed

I'm closing this, in favor of one of the suggestions--create a new store, tentatively to be called (subject to better ideas), AndOrWriteStore?. I'll submit on a new ticket, with test file and unit test. Thanks.

comment:8 Changed 11 years ago by Jared Jurkiewicz


Awesome. The general intention is to implement stores for specific purposes, as trying to build one store that covered every possible case/behavior/thing people would want would be a fairly impossible task. I highly recommend that you support the simple AND style syntax all base stores do, and make your complex queries additional capabilities. That will keep you store working with simple widgets like ComboBox?, while still allowing for more complex queries.

-- Jared

Note: See TracTickets for help on using tickets.