: e.g. For the following query that looks for a file in a directory: : q=+directory_name:"myDirectory" +file_name:"myFile" : : We'd need to decompose the query into the following two queries: : 1. q=+directory_name:"myDirectory"&fl=directory_id : 2. q=+file_name:"myFile" +directory_id:(results from query #1) : : I guess I'm looking for the following feedback: : - Does this sound crazy?
it's a little crazy, but not absurd. : - Is the QParser the right place for this logic? If so, can I get a : little more guidance on how to decompose the queries there (filter : queries maybe)? a QParser could work. (and in general, if you can solve something with a QParser that's probably for the best, since it allows the most reuse). but exactly how to do it depends on how many results you expect from your first query: if you are going to structure things so they have to uniquely id a directory, and you'll have a singleID, then this is something that could easily make sense in a QParser (you are essentailly just rewriting part of the query from string to id -- you just happen to be using solr as a lookup table for those strings). but if you plan to support any arbitrary "N" directories, then you may need something more complicated ... straight filter queries won't help much because you'll want the union instead of hte intersection, so for every directoryId you find, use it as a query to get a DocSet and then maintain a running union of all those DocSets to use as your final filter (hmm... that may not actually be possible with the QParser API ... i haven't look at ti in a while, but for an approach like this you may beed to subclass QueryComponent instead) -Hoss
