> 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.)
