Thanks for the response. I went ahead and gave it a shot. In my case, the directory name may not be unique so if I get multiple ids back then I create a BooleanQuery (Occur.SHOULD) to substitute the directory name query. This seems to work at the moment so hopefully that's the right approach.
Thanks, Laurent Vauthrin -----Original Message----- From: solr-user-return-30054-laurent.vauthrin=disney....@lucene.apache.org [mailto:solr-user-return-30054-laurent.vauthrin=disney....@lucene.apache .org] On Behalf Of Chris Hostetter Sent: Monday, December 07, 2009 12:17 PM To: solr-user@lucene.apache.org Subject: RE: SolrPlugin Guidance : 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
