> 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 I think that's missing the need for an argument for what field in the solr index to require to be within the values generated by the SQL? Or maybe it's meant to assume the identifier field, but it would be an interesting generalization to allow any field. q=solr&fq={!sql field=id}SELECT ID FROM USER_MAP WHERE USER=1234 ORDER BY ID ASC And then, thinking further, in addition to an external sql, how about generalize this to an alternate 'sub' query on the solr index itself? q=solr&fq={!join_query field=id =id}foo:bar AND something_else ['subquery' is already taken as a defType, for purposes not entirely suitable here... I think? ] Or even a different core! q=solr&fq={!join_query core=different_one field=id on_stored_field=id}foo:bar AND something_else If that could be done as efficiently as reasonable, it would actually solve a whole BUNCH of problem cases that come up now and then. (And yes, people would have to be cautioned not to immediately use this type of solution becuase they are used to thinking in terms of rdbms; but for some problems it really would allow things just not easily possible otherwise.)