1.0Aeologic Bloghttps://www.aeologic.com/blogrich600338<blockquote class="wp-embedded-content" data-secret="B1no2KugRH"><a href="https://www.aeologic.com/blog/learning-to-rank19-transforming-result-documents/">Transforming Result Documents – Ultimate Solr Guide</a></blockquote><iframe sandbox="allow-scripts" security="restricted" src="https://www.aeologic.com/blog/learning-to-rank19-transforming-result-documents/embed/#?secret=B1no2KugRH" width="600" height="338" title="“Transforming Result Documents – Ultimate Solr Guide” — Aeologic Blog" data-secret="B1no2KugRH" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" class="wp-embedded-content"></iframe><script> /*! This file is auto-generated */ !function(d,l){"use strict";l.querySelector&&d.addEventListener&&"undefined"!=typeof URL&&(d.wp=d.wp||{},d.wp.receiveEmbedMessage||(d.wp.receiveEmbedMessage=function(e){var t=e.data;if((t||t.secret||t.message||t.value)&&!/[^a-zA-Z0-9]/.test(t.secret)){for(var s,r,n,a=l.querySelectorAll('iframe[data-secret="'+t.secret+'"]'),o=l.querySelectorAll('blockquote[data-secret="'+t.secret+'"]'),c=new RegExp("^https?:$","i"),i=0;i<o.length;i++)o[i].style.display="none";for(i=0;i<a.length;i++)s=a[i],e.source===s.contentWindow&&(s.removeAttribute("style"),"height"===t.message?(1e3<(r=parseInt(t.value,10))?r=1e3:~~r<200&&(r=200),s.height=r):"link"===t.message&&(r=new URL(s.getAttribute("src")),n=new URL(t.value),c.test(n.protocol))&&n.host===r.host&&l.activeElement===s&&(d.top.location.href=t.value))}},d.addEventListener("message",d.wp.receiveEmbedMessage,!1),l.addEventListener("DOMContentLoaded",function(){for(var e,t,s=l.querySelectorAll("iframe.wp-embedded-content"),r=0;r<s.length;r++)(t=(e=s[r]).getAttribute("data-secret"))||(t=Math.random().toString(36).substring(2,12),e.src+="#?secret="+t,e.setAttribute("data-secret",t)),e.contentWindow.postMessage({message:"ready",secret:t},"*")},!1)))}(window,document); //# sourceURL=https://www.aeologic.com/blog/wp-includes/js/wp-embed.min.js </script> https://www.aeologic.com/blog/wp-content/uploads/2020/06/Transforming-Result-Documents-in-solr-1.png1080622Document Transformers modify the information returned about documents in the results of a query. Using Document Transformers When executing a request, a document transformer can be used by including it in the fl parameter using square brackets, for example: fl=id,name,score,[shard] Some transformers allow, or require, local parameters which can be specified as key value pairs inside the brackets: fl=id,name,score,[explain style=nl] As with regular fields, you can change the key used when a Transformer adds a field to a document via a prefix: fl=id,name,score,my_val_a:[value v=42 t=int],my_val_b:[value v=7 t=float] The sections below discuss exactly what these various transformers do. Available Transformers [value] – ValueAugmenterFactory Modifies every document to include the exact same value, as if it were a stored field in every document: q=*:*&fl=id,greeting:[value v='hello']&wt=xml The above query would produce results like the following: <result name="response" numFound="32" start="0"> <doc> <str name="id">1</str> <str name="greeting">hello</str></doc> </doc> ... By default, values are returned as a String, but a t parameter can be specified using a value of int, float, double, or date to force a specific return type: q=*:*&fl=id,my_number:[value v=42 t=int],my_string:[value v=42] In addition to using these request parameters, you can configure additional named instances of ValueAugmenterFactory, or override the default behavior of the existing [value] transformer in your solrconfig.xml file: <transformer name="mytrans2" class="org.apache.solr.response.transform.ValueAugmenterFactory" > <int name="value">5</int> </transformer> <transformer name="value" class="org.apache.solr.response.transform.ValueAugmenterFactory" > <double name="defaultValue">5</double> </transformer> The value option forces an explicit value to always be used, while the defaultValue option provides a default that can still be overridden using the v and t local parameters. [explain] – ExplainAugmenterFactory Augments each document with an inline explanation of its score exactly like the information available about each document in the debug section: q=features:cache&fl=id,[explain style=nl] Supported values for style are text, html, and nl which returns the information as structured data. Here is the output of the above request using style=nl: { "response":{"numFound":2,"start":0,"docs":[ { "id":"6H500F0", "[explain]":{ "match":true, "value":1.052226, "description":"weight(features:cache in 2) [DefaultSimilarity], result of:", "details":[{ }]}}]}} A default style can be configured by specifying an args parameter in your solrconfig.xml configuration: <transformer name="explain" class="org.apache.solr.response.transform.ExplainAugmenterFactory" > <str name="args">nl</str> </transformer> [child] – ChildDocTransformerFactory This transformer returns all descendant documents of each parent document matching your query in a flat list nested inside the matching parent document. This is useful when you have indexed nested child documents and want to retrieve the child documents for the relevant parent documents for any type of search query. fl=id,[child parentFilter=doc_type:book childFilter=doc_type:chapter limit=100] Note that this transformer can be used even though the query itself is not a Block Join query. When using this transformer, the parentFilter parameter must be specified unless the schema declares _nest_path_. It works the same as in all Block Join Queries. Additional optional parameters are:childFilterA query to filter which child documents should be included. This can be particularly useful when you have multiple levels of hierarchical documents. The default is all children. This query supports a special syntax to match nested doc patterns so long as _nest_path_ is defined in the schema and the query contains a / preceding the first :. Example: childFilter=/comments/content:recipe Further details of this are experimental.limitThe maximum number of child documents to be returned per parent document. The default is 10.fl The field list which the transformer is to return. The default is the top level fl). There is a further limitation in which the fields here should be a subset of those specified by the top level fl parameter. [shard] – ShardAugmenterFactory This transformer adds information about what shard each individual document came from in a distributed request. ShardAugmenterFactory does not support any request parameters, or configuration options. [docid] – DocIdAugmenterFactory This transformer adds the internal Lucene document id to each document – this is primarily only useful for debugging purposes. DocIdAugmenterFactory does not support any request parameters, or configuration options. [elevated] and [excluded] These transformers are available only when using the Query Elevation Component. [elevated] annotates each document to indicate if it was elevated or not. [excluded] annotates each document to indicate if it would have been excluded – this is only supported if you also use the markExcludes parameter. fl=id,[elevated],[excluded]&excludeIds=GB18030TEST&elevateIds=6H500F0&markExcludes=true { "response":{"numFound":32,"start":0,"docs":[ { "id":"6H500F0", "[elevated]":true, "[excluded]":false}, { "id":"GB18030TEST", "[elevated]":false, "[excluded]":true}, { "id":"SP2514N", "[elevated]":false, "[excluded]":false}, ]}} [json] / [xml] These transformers replace a field value containing a string representation of a valid XML or JSON structure with the actual raw XML or JSON structure instead of just the string value. Each applies only to the specific writer, such that [json] only applies to wt=json and [xml] only applies to wt=xml. fl=id,source_s:[json]&wt=json [subquery] This transformer executes a separate query per transforming document passing document fields as an input for subquery parameters. It’s usually used with {!join} and {!parent} query parsers, and is intended to be an improvement for [child]. It must be given an unique name: fl=*,children:[subquery] There might be a few of them, e.g., fl=*,sons:[subquery],daughters:[subquery]. Every [subquery] occurrence adds a field into a result document with the given name, the value of this field is a document list, which is a result of executing subquery using document fields as an input. Subquery will use the /select search handler by default, and will return an error if /select is not configured. This can be changed by supplying foo.qt parameter. Here is how it looks like using various formats:XML <result name="response" numFound="2" start="0"> <doc> <int name="id">1</int> <arr name="title"> <str>vdczoypirs</str> </arr> <result name="children" numFound="1" start="0"> <doc> <int name="id">2</int> <arr name="title"> <str>vdczoypirs</str> </arr> </doc> </result> </doc> ... JSON { "response":{ "numFound":2, "start":0, "docs":[ { "id":1, "subject":["parentDocument"], "title":["xrxvomgu"], "children":{ "numFound":1, "start":0, "docs":[ { "id":2, "cat":["childDocument"] } ] }}]}} SolrJ SolrDocumentList subResults = (SolrDocumentList)doc.getFieldValue("children"); Subquery Result Fields To appear in subquery document list, a field should be specified in both fl parameters: in the main fl (despite the main result documents have no this field), and in subquery’s fl (e.g., foo.fl). Wildcards can be used in one or both of these parameters. For example, if field title should appear in categories subquery, it can be done via one of these ways: fl=...title,categories:[subquery]&categories.fl=title&categories.q=... fl=...title,categories:[subquery]&categories.fl=*&categories.q=... fl=...*,categories:[subquery]&categories.fl=title&categories.q=... fl=...*,categories:[subquery]&categories.fl=*&categories.q=... Subquery Parameters Shift If a subquery is declared as fl=*,foo:[subquery], subquery parameters are prefixed with the given name and period. For example: q=*:*&fl=*,**foo**:[subquery]&**foo.**q=to be continued&**foo.**rows=10&**foo.**sort=id desc Document Field as an Input for Subquery Parameters It’s necessary to pass some document field values as a parameter for subquery. It’s supported via an implicit row.fieldname parameter, and can be (but might not only) referred via local parameters syntax: q=name:john&fl=name,id,depts:[subquery]&depts.q={!terms f=id v=$row.dept_id}&depts.rows=10 Here departments are retrieved per every employee in search result. We can say that it’s like SQL join ON emp.dept_id=dept.id. Note, when a document field has […]