: Hoss mentioned a couple of ideas:
: 1) sub-classing query parser
: 2) Having the app query a database and somehow passing something
: to Solr or lucene for the filter query
The approach i was refering to is something one of my coworkers did a
while back (if he's still lurking on the list, maybe he'll speak up)
He implemented a custom "SqlFilterQuery" class that was constructed from a
JDBC URL and a SQL statement. the SqlQuery class rewrote to itself (so it
was a primitive query class) and returned a Scorer method that would:
1) execute the SQL query (which should return a sorted list of uniqueKey
field values) and retrieve a JDBC iterator (cursor?) over the results.
2) fetch a TermEnum from Lucene for the uniqueKey field
3) use the JDBC Iterator to skip ahead on the TermEnum and for each
uniqueKey to get the underlying lucene docid, and record it in a DocSet
As i recall, my coworker was using this in a custom RequestHandler, where
he was then forcibly putting that DocSet in the filterCache so that it
would be there on future requests, and it would be regenerated by
autoWarming (the advantage of implementing this logic using the Query
interface) but it could also be done with a custom cache if you don't want
these to contend for space in the filterCache.
My point aout hte query parser was that instead of needing to use a custom
RequestHandler (or even a custom SearchCOmponent) to generate this DocSet
for filtering, you could probably do it using a QParserPlugin -- that way
you could use a regaulr "fq" param to generate the filter. You could even
generalize the hell out of it so the SQL itself could be specified at
request time...
q=solr&fq={!sql}SELECT ID FROM USER_MAP WHERE USER=1234 ORDER BY ID ASC
-Hoss
