More recently, due to requests from the community, pseudo-join queries have been added to filter documents at runtime by applying conditions to another document value. A pseudo-join query can be executed as follows:
- It's very easy to execute a pseudo-join query, as you will find it very similar to the nested queries seen earlier:
>> curl -X GET 'http://localhost:8983/solr/paintings/select?fl=title,artist&q=abstract:paintings%20AND%20{!join%20from=artist%20to=title}artist:vermeer'This query simply returns again the document for Dalì's painting The Ghost of Vermeer of Delft Which Can Be Used As a Table.
- Note that the characters
{and}need to be escaped withor substituted by the correct HTTP encoding. If we rewrite the cURL command as follows, the query will be much more readable, and we can still contain the output format in the usual way, separating it from the parameters containing the query itself:>> curl -X GET 'http://localhost:8983/solr/paintings/select?fl=title,artist&wt=json' --data-urlencode 'q=abstract:paintings AND {!join from=artist to=title}artist:vermeer'
Here we are querying in the documents containing the term painting in the abstract field, and then joining them over the documents that contain the vermer term in the artist field, and has some match in the title with the artist field. This is a very particular case, and gives us the possibility of using it for some considerations.
If you have some experience with SQL, you will be familiar with the following code:
/solr/paintings/select?
fl=title,artist
q=abstract:paintings AND {!join from=artist to=title}artist:vermeer The following is a slight analogy to an inner SQL query:
SELECT title,artist FROM paintings WHERE (abstract:paintings AND (title IN (SELECT artist FROM paintings where artist:vermeer))
This does not suggest that we should start using Solr with a pseudo-SQL approach, but there can be cases where we need to filter out some documents from the result, if they don't match a certain criteria in another document field. I must inform you that these are usually some very particular use cases.
One of the most recurring and recognizable front-end patterns while performing searches is the ability to provide results to the users with the matching terms obvious, in order to make them more recognizable. Using such an ability together with the flexibility of an Edismax parser would probably be the best choice for several simple applications.