{"id":1309,"date":"2020-06-08T04:13:28","date_gmt":"2020-06-08T04:13:28","guid":{"rendered":"https:\/\/www.aeologic.com\/insights\/?p=1309"},"modified":"2020-06-15T07:46:26","modified_gmt":"2020-06-15T07:46:26","slug":"ultimate-solr-guide14-the-standard-query-parser","status":"publish","type":"post","link":"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/","title":{"rendered":"The Standard Query Parser &#8211; Ultimate Solr Guide"},"content":{"rendered":"\n<p>Solr\u2019s default Query Parser is also known as the \u201c<code>lucene<\/code>\u201d parser.<\/p>\n\n\n\n<p>The key advantage of the standard query parser is that it supports a robust and fairly intuitive syntax allowing you to create a variety of structured queries. The largest disadvantage is that it\u2019s very intolerant of syntax errors, as compared with something like the&nbsp;<a href=\"https:\/\/lucene.apache.org\/solr\/guide\/8_5\/the-dismax-query-parser.html#the-dismax-query-parser\">DisMax<\/a>&nbsp;query parser which is designed to throw as few errors as possible.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"standard-query-parser-parameters\">Standard Query Parser Parameters<\/h2>\n\n\n\n<p>In addition to the&nbsp;<a href=\"https:\/\/lucene.apache.org\/solr\/guide\/8_5\/common-query-parameters.html#common-query-parameters\">Common Query Parameters<\/a>,&nbsp;<a href=\"https:\/\/lucene.apache.org\/solr\/guide\/8_5\/faceting.html#faceting\">Faceting Parameters<\/a>,&nbsp;<a href=\"https:\/\/lucene.apache.org\/solr\/guide\/8_5\/highlighting.html#highlighting\">Highlighting Parameters<\/a>, and&nbsp;<a href=\"https:\/\/lucene.apache.org\/solr\/guide\/8_5\/morelikethis.html#morelikethis\">MoreLikeThis Parameters<\/a>, the standard query parser supports the parameters described in the table below.<code>q<\/code>Defines a query using standard query syntax. This parameter is mandatory.<code>q.op<\/code>Specifies the default operator for query expressions. Possible values are &#8220;AND&#8221; or &#8220;OR&#8221;.<code>df<\/code>Specifies a default searchable field.<code>sow<\/code>Split on whitespace. If set to&nbsp;<code>true<\/code>, text analysis is invoked separately for each individual whitespace-separated term. The default is&nbsp;<code>false<\/code>; whitespace-separated term sequences will be provided to text analysis in one shot, enabling proper function of analysis filters that operate over term sequences, e.g., multi-word synonyms and shingles.<\/p>\n\n\n\n<p>Default parameter values are specified in&nbsp;<code>solrconfig.xml<\/code>, or overridden by query-time values in the request.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"standard-query-parser-response\">Standard Query Parser Response<\/h2>\n\n\n\n<p>By default, the response from the standard query parser contains one&nbsp;<code>&lt;result&gt;<\/code>&nbsp;block, which is unnamed. If the&nbsp;<a href=\"https:\/\/lucene.apache.org\/solr\/guide\/8_5\/common-query-parameters.html#debug-parameter\"><code>debug<\/code>&nbsp;parameter<\/a>&nbsp;is used, then an additional&nbsp;<code>&lt;lst&gt;<\/code>&nbsp;block will be returned, using the name &#8220;debug&#8221;. This will contain useful debugging info, including the original query string, the parsed query string, and explain info for each document in the &lt;result&gt; block. If the&nbsp;<a href=\"https:\/\/lucene.apache.org\/solr\/guide\/8_5\/common-query-parameters.html#explainother-parameter\"><code>explainOther<\/code>&nbsp;parameter<\/a>&nbsp;is also used, then additional explain info will be provided for all the documents matching that query.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"specifying-terms-for-the-standard-query-parser\">Specifying Terms for the Standard Query Parser<\/h2>\n\n\n\n<p>A query to the standard query parser is broken up into terms and operators. There are two types of terms: single terms and phrases.<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>A single term is a single word such as &#8220;test&#8221; or &#8220;hello&#8221;<\/li><li>A phrase is a group of words surrounded by double quotes such as &#8220;hello dolly&#8221;<\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"term-modifiers\">Term Modifiers<\/h3>\n\n\n\n<p>Solr supports a variety of term modifiers that add flexibility or precision, as needed, to searches. These modifiers include wildcard characters, characters for making a search &#8220;fuzzy&#8221; or more general, and so on. The sections below describe these modifiers in detail.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"wildcard-searches\">Wildcard Searches<\/h3>\n\n\n\n<p>Solr\u2019s standard query parser supports single and multiple character wildcard searches within single terms. Wildcard characters can be applied to single terms, but not to search phrases.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Wildcard Search Type<\/th><th>Special Character<\/th><th>Example<\/th><\/tr><\/thead><tbody><tr><td>Single character (matches a single character)<\/td><td>?<\/td><td>The search string&nbsp;<code>te?t<\/code>&nbsp;would match both test and text.<\/td><\/tr><tr><td>Multiple characters (matches zero or more sequential characters)<\/td><td>*<\/td><td>The wildcard search:&nbsp;<code>tes*<\/code>&nbsp;would match test, testing, and tester. You can also use wildcard characters in the middle of a term. For example:&nbsp;<code>te*t<\/code>&nbsp;would match test and text.&nbsp;<code>*est<\/code>&nbsp;would match pest and test.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"fuzzy-searches\">Fuzzy Searches<\/h3>\n\n\n\n<p>Solr\u2019s standard query parser supports fuzzy searches based on the Damerau-Levenshtein Distance or Edit Distance algorithm. Fuzzy searches discover terms that are similar to a specified term without necessarily being an exact match. To perform a fuzzy search, use the tilde ~ symbol at the end of a single-word term. For example, to search for a term similar in spelling to &#8220;roam,&#8221; use the fuzzy search:<\/p>\n\n\n\n<p><code>roam~<\/code><\/p>\n\n\n\n<p>This search will match terms like roams, foam, &amp; foams. It will also match the word &#8220;roam&#8221; itself.<\/p>\n\n\n\n<p>An optional distance parameter specifies the maximum number of edits allowed, between 0 and 2, defaulting to 2. For example:<\/p>\n\n\n\n<p><code>roam~1<\/code><\/p>\n\n\n\n<p>This will match terms like roams &amp; foam &#8211; but not foams since it has an edit distance of &#8220;2&#8221;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"proximity-searches\">Proximity Searches<\/h3>\n\n\n\n<p>A proximity search looks for terms that are within a specific distance from one another.<\/p>\n\n\n\n<p>To perform a proximity search, add the tilde character ~ and a numeric value to the end of a search phrase. For example, to search for a &#8220;apache&#8221; and &#8220;jakarta&#8221; within 10 words of each other in a document, use the search:<\/p>\n\n\n\n<p><code>\"jakarta apache\"~10<\/code><\/p>\n\n\n\n<p>The distance referred to here is the number of term movements needed to match the specified phrase. In the example above, if &#8220;apache&#8221; and &#8220;jakarta&#8221; were 10 spaces apart in a field, but &#8220;apache&#8221; appeared before &#8220;jakarta&#8221;, more than 10 term movements would be required to move the terms together and position &#8220;apache&#8221; to the right of &#8220;jakarta&#8221; with a space in between.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"existence-searches\">Existence Searches<\/h3>\n\n\n\n<p>An existence search for a field matches all documents where a value exists for that field. To query for a field existing, simply use a wildcard instead of a term in the search.<\/p>\n\n\n\n<p><code>field:*<\/code><\/p>\n\n\n\n<p>A field will be considered to &#8220;exist&#8221; if it has any value, even values which are often considered &#8220;not existent&#8221;. (e.g.,&nbsp;<code>NaN<\/code>,&nbsp;<code>\"\"<\/code>, etc.)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"range-searches\">Range Searches<\/h3>\n\n\n\n<p>A range search specifies a range of values for a field (a range with an upper bound and a lower bound). The query matches documents whose values for the specified field or fields fall within the range. Range queries can be inclusive or exclusive of the upper and lower bounds. Sorting is done lexicographically, except on numeric fields. For example, the range query below matches all documents whose&nbsp;<code>popularity<\/code>&nbsp;field has a value between 52 and 10,000, inclusive.<\/p>\n\n\n\n<p><code>popularity:[52 TO 10000]<\/code><\/p>\n\n\n\n<p>Range queries are not limited to date fields or even numerical fields. You could also use range queries with non-date fields:<\/p>\n\n\n\n<p><code>title:{Aida TO Carmen}<\/code><\/p>\n\n\n\n<p>This will find all documents whose titles are between Aida and Carmen, but not including Aida and Carmen.<\/p>\n\n\n\n<p>The brackets around a query determine its inclusiveness.<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>Square brackets&nbsp;<code>[<\/code>&nbsp;&amp;&nbsp;<code>]<\/code>&nbsp;denote an inclusive range query that matches values including the upper and lower bound.<\/li><li>Curly brackets&nbsp;<code>{<\/code>&nbsp;&amp;&nbsp;<code>}<\/code>&nbsp;denote an exclusive range query that matches values between the upper and lower bounds, but excluding the upper and lower bounds themselves.<\/li><li>You can mix these types so one end of the range is inclusive and the other is exclusive. Here\u2019s an example:&nbsp;<code>count:{1 TO 10]<\/code><\/li><\/ul>\n\n\n\n<p>Wildcards,&nbsp;<code>*<\/code>, can also be used for either or both endpoints to specify an open-ended range query. This is a&nbsp;<a href=\"https:\/\/lucene.apache.org\/solr\/guide\/8_5\/the-standard-query-parser.html#differences-between-lucenes-classic-query-parser-and-solrs-standard-query-parser\">divergence from Lucene\u2019s Classic Query Parser<\/a>.<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><code>field:[* TO 100]<\/code>&nbsp;finds all field values less than or equal to 100.<\/li><li><code>field:[100 TO *]<\/code>&nbsp;finds all field values greater than or equal to 100.<\/li><li><code>field:[* TO *]<\/code>&nbsp;finds any document with a value between the effective values of -Infinity and +Infinity for that field type.<\/li><\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"boosting-a-term-with\">Boosting a Term with &#8220;^&#8221;<\/h3>\n\n\n\n<p>Lucene\/Solr provides the relevance level of matching documents based on the terms found. To boost a term use the caret symbol&nbsp;<code>^<\/code>&nbsp;with a boost factor (a number) at the end of the term you are searching. The higher the boost factor, the more relevant the term will be.<\/p>\n\n\n\n<p>Boosting allows you to control the relevance of a document by boosting its term. For example, if you are searching for<\/p>\n\n\n\n<p>&#8220;jakarta apache&#8221; and you want the term &#8220;jakarta&#8221; to be more relevant, you can boost it by adding the ^ symbol along with the boost factor immediately after the term. For example, you could type:<\/p>\n\n\n\n<p><code>jakarta^4 apache<\/code><\/p>\n\n\n\n<p>This will make documents with the term jakarta appear more relevant. You can also boost Phrase Terms as in the example:<\/p>\n\n\n\n<p><code>\"jakarta apache\"^4 \"Apache Lucene\"<\/code><\/p>\n\n\n\n<p>By default, the boost factor is 1. Although the boost factor must be positive, it can be less than 1 (for example, it could be 0.2).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"constant-score-with\">Constant Score with &#8220;^=&#8221;<\/h3>\n\n\n\n<p>Constant score queries are created with&nbsp;<code>&lt;query_clause&gt;^=&lt;score&gt;<\/code>, which sets the entire clause to the specified score for any documents matching that clause. This is desirable when you only care about matches for a particular clause and don\u2019t want other relevancy factors such as term frequency (the number of times the term appears in the field) or inverse document frequency (a measure across the whole index for how rare a term is in a field).<\/p>\n\n\n\n<p>Example:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>(description:blue OR color:blue)^=1.0 text:shoes<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"querying-specific-fields\">Querying Specific Fields<\/h2>\n\n\n\n<p>Data indexed in Solr is organized in fields, which are&nbsp;<a href=\"https:\/\/lucene.apache.org\/solr\/guide\/8_5\/defining-fields.html#defining-fields\">defined in the Solr Schema<\/a>. Searches can take advantage of fields to add precision to queries. For example, you can search for a term only in a specific field, such as a title field.<\/p>\n\n\n\n<p>The Schema defines one field as a default field. If you do not specify a field in a query, Solr searches only the default field. Alternatively, you can specify a different field or a combination of fields in a query.<\/p>\n\n\n\n<p>To specify a field, type the field name followed by a colon &#8220;:&#8221; and then the term you are searching for within the field.<\/p>\n\n\n\n<p>For example, suppose an index contains two fields, title and text,and that text is the default field. If you want to find a document called &#8220;The Right Way&#8221; which contains the text &#8220;don\u2019t go this way,&#8221; you could include either of the following terms in your search query:<\/p>\n\n\n\n<p><code>title:\"The Right Way\" AND text:go<\/code><\/p>\n\n\n\n<p><code>title:\"Do it right\" AND go<\/code><\/p>\n\n\n\n<p>Since text is the default field, the field indicator is not required; hence the second query above omits it.<\/p>\n\n\n\n<p>The field is only valid for the term that it directly precedes, so the query&nbsp;<code>title:Do it right<\/code>&nbsp;will find only &#8220;Do&#8221; in the title field. It will find &#8220;it&#8221; and &#8220;right&#8221; in the default field (in this case the text field).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"grouping-terms-to-form-sub-queries\">Grouping Terms to Form Sub-Queries<\/h2>\n\n\n\n<p>Lucene\/Solr supports using parentheses to group clauses to form sub-queries. This can be very useful if you want to control the Boolean logic for a query.<\/p>\n\n\n\n<p>The query below searches for either &#8220;jakarta&#8221; or &#8220;apache&#8221; and &#8220;website&#8221;:<\/p>\n\n\n\n<p><code>(jakarta OR apache) AND website<\/code><\/p>\n\n\n\n<p>This adds precision to the query, requiring that the term &#8220;website&#8221; exist, along with either term &#8220;jakarta&#8221; and &#8220;apache.&#8221;<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"grouping-clauses-within-a-field\">Grouping Clauses within a Field<\/h3>\n\n\n\n<p>To apply two or more Boolean operators to a single field in a search, group the Boolean clauses within parentheses. For example, the query below searches for a title field that contains both the word &#8220;return&#8221; and the phrase &#8220;pink panther&#8221;:<\/p>\n\n\n\n<p><code>title:(+return +\"pink panther\")<\/code><\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"comments-in-queries\">Comments in Queries<\/h2>\n\n\n\n<p>C-Style comments are supported in query strings.<\/p>\n\n\n\n<p>Example:<\/p>\n\n\n\n<p><code>\"jakarta apache\" \/* this is a comment in the middle of a normal query string *\/ OR jakarta<\/code><\/p>\n\n\n\n<p>Comments may be nested.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"specifying-dates-and-times\">Specifying Dates and Times<\/h3>\n\n\n\n<p>Queries against date based fields must use the&nbsp;<a href=\"https:\/\/lucene.apache.org\/solr\/guide\/8_5\/working-with-dates.html#working-with-dates\">appropriate date formating<\/a>. Queries for exact date values will require quoting or escaping since&nbsp;<code>:<\/code>&nbsp;is the parser syntax used to denote a field query:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><code>createdate:1976-03-06T23\\:59\\:59.999Z<\/code><\/li><li><code>createdate:\"1976-03-06T23:59:59.999Z\"<\/code><\/li><li><code>createdate:[1976-03-06T23:59:59.999Z TO *]<\/code><\/li><li><code>createdate:[1995-12-31T23:59:59.999Z TO 2007-03-06T00:00:00Z]<\/code><\/li><li><code>timestamp:[* TO NOW]<\/code><\/li><li><code>pubdate:[NOW-1YEAR\/DAY TO NOW\/DAY+1DAY]<\/code><\/li><li><code>createdate:[1976-03-06T23:59:59.999Z TO 1976-03-06T23:59:59.999Z+1YEAR]<\/code><\/li><li><code>createdate:[1976-03-06T23:59:59.999Z\/YEAR TO 1976-03-06T23:59:59.999Z]<\/code><\/li><\/ul>\n\n\n\n<p>So, this is it for today. Stay tuned for more such posts in future.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Solr\u2019s default Query Parser is also known as the \u201clucene\u201d parser. The key advantage of the standard query parser is that it supports a robust and fairly intuitive syntax allowing you to create a variety of structured queries. The largest disadvantage is that it\u2019s very intolerant of syntax errors, as compared with something like the&nbsp;DisMax&nbsp;query parser which is designed to throw as few errors as possible. Standard Query Parser Parameters In addition to the&nbsp;Common Query Parameters,&nbsp;Faceting Parameters,&nbsp;Highlighting Parameters, and&nbsp;MoreLikeThis Parameters, the standard query parser supports the parameters described in the table below.qDefines a query using standard query syntax. This parameter is mandatory.q.opSpecifies the default operator for query expressions. Possible values are &#8220;AND&#8221; or &#8220;OR&#8221;.dfSpecifies a default searchable field.sowSplit on whitespace. If set to&nbsp;true, text analysis is invoked separately for each individual whitespace-separated term. The default is&nbsp;false; whitespace-separated term sequences will be provided to text analysis in one shot, enabling proper function of analysis filters that operate over term sequences, e.g., multi-word synonyms and shingles. Default parameter values are specified in&nbsp;solrconfig.xml, or overridden by query-time values in the request. Standard Query Parser Response By default, the response from the standard query parser contains one&nbsp;&lt;result&gt;&nbsp;block, which is unnamed. If the&nbsp;debug&nbsp;parameter&nbsp;is used, then an additional&nbsp;&lt;lst&gt;&nbsp;block will be returned, using the name &#8220;debug&#8221;. This will contain useful debugging info, including the original query string, the parsed query string, and explain info for each document in the &lt;result&gt; block. If the&nbsp;explainOther&nbsp;parameter&nbsp;is also used, then additional explain info will be provided for all the documents matching that query. Specifying Terms for the Standard Query Parser A query to the standard query parser is broken up into terms and operators. There are two types of terms: single terms and phrases. A single term is a single word such as &#8220;test&#8221; or &#8220;hello&#8221; A phrase is a group of words surrounded by double quotes such as &#8220;hello dolly&#8221; Term Modifiers Solr supports a variety of term modifiers that add flexibility or precision, as needed, to searches. These modifiers include wildcard characters, characters for making a search &#8220;fuzzy&#8221; or more general, and so on. The sections below describe these modifiers in detail. Wildcard Searches Solr\u2019s standard query parser supports single and multiple character wildcard searches within single terms. Wildcard characters can be applied to single terms, but not to search phrases. Wildcard Search Type Special Character Example Single character (matches a single character) ? The search string&nbsp;te?t&nbsp;would match both test and text. Multiple characters (matches zero or more sequential characters) * The wildcard search:&nbsp;tes*&nbsp;would match test, testing, and tester. You can also use wildcard characters in the middle of a term. For example:&nbsp;te*t&nbsp;would match test and text.&nbsp;*est&nbsp;would match pest and test. Fuzzy Searches Solr\u2019s standard query parser supports fuzzy searches based on the Damerau-Levenshtein Distance or Edit Distance algorithm. Fuzzy searches discover terms that are similar to a specified term without necessarily being an exact match. To perform a fuzzy search, use the tilde ~ symbol at the end of a single-word term. For example, to search for a term similar in spelling to &#8220;roam,&#8221; use the fuzzy search: roam~ This search will match terms like roams, foam, &amp; foams. It will also match the word &#8220;roam&#8221; itself. An optional distance parameter specifies the maximum number of edits allowed, between 0 and 2, defaulting to 2. For example: roam~1 This will match terms like roams &amp; foam &#8211; but not foams since it has an edit distance of &#8220;2&#8221; Proximity Searches A proximity search looks for terms that are within a specific distance from one another. To perform a proximity search, add the tilde character ~ and a numeric value to the end of a search phrase. For example, to search for a &#8220;apache&#8221; and &#8220;jakarta&#8221; within 10 words of each other in a document, use the search: &#8220;jakarta apache&#8221;~10 The distance referred to here is the number of term movements needed to match the specified phrase. In the example above, if &#8220;apache&#8221; and &#8220;jakarta&#8221; were 10 spaces apart in a field, but &#8220;apache&#8221; appeared before &#8220;jakarta&#8221;, more than 10 term movements would be required to move the terms together and position &#8220;apache&#8221; to the right of &#8220;jakarta&#8221; with a space in between. Existence Searches An existence search for a field matches all documents where a value exists for that field. To query for a field existing, simply use a wildcard instead of a term in the search. field:* A field will be considered to &#8220;exist&#8221; if it has any value, even values which are often considered &#8220;not existent&#8221;. (e.g.,&nbsp;NaN,&nbsp;&#8220;&#8221;, etc.) Range Searches A range search specifies a range of values for a field (a range with an upper bound and a lower bound). The query matches documents whose values for the specified field or fields fall within the range. Range queries can be inclusive or exclusive of the upper and lower bounds. Sorting is done lexicographically, except on numeric fields. For example, the range query below matches all documents whose&nbsp;popularity&nbsp;field has a value between 52 and 10,000, inclusive. popularity:[52 TO 10000] Range queries are not limited to date fields or even numerical fields. You could also use range queries with non-date fields: title:{Aida TO Carmen} This will find all documents whose titles are between Aida and Carmen, but not including Aida and Carmen. The brackets around a query determine its inclusiveness. Square brackets&nbsp;[&nbsp;&amp;&nbsp;]&nbsp;denote an inclusive range query that matches values including the upper and lower bound. Curly brackets&nbsp;{&nbsp;&amp;&nbsp;}&nbsp;denote an exclusive range query that matches values between the upper and lower bounds, but excluding the upper and lower bounds themselves. You can mix these types so one end of the range is inclusive and the other is exclusive. Here\u2019s an example:&nbsp;count:{1 TO 10] Wildcards,&nbsp;*, can also be used for either or both endpoints to specify an open-ended range query. This is a&nbsp;divergence from Lucene\u2019s Classic Query Parser. field:[* TO 100]&nbsp;finds all field values less than or equal to 100. field:[100 TO *]&nbsp;finds all field values greater than or equal to 100. field:[* TO *]&nbsp;finds any document with a [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":1346,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[41],"tags":[115,114,113,116],"class_list":["post-1309","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-solr","tag-parser","tag-query-parser","tag-solr-parser","tag-standard-query-parser"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v23.1 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>The Standard Query Parser - Ultimate Solr Guide - Aeologic Blog<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"The Standard Query Parser - Ultimate Solr Guide - Aeologic Blog\" \/>\n<meta property=\"og:description\" content=\"Solr\u2019s default Query Parser is also known as the \u201clucene\u201d parser. The key advantage of the standard query parser is that it supports a robust and fairly intuitive syntax allowing you to create a variety of structured queries. The largest disadvantage is that it\u2019s very intolerant of syntax errors, as compared with something like the&nbsp;DisMax&nbsp;query parser which is designed to throw as few errors as possible. Standard Query Parser Parameters In addition to the&nbsp;Common Query Parameters,&nbsp;Faceting Parameters,&nbsp;Highlighting Parameters, and&nbsp;MoreLikeThis Parameters, the standard query parser supports the parameters described in the table below.qDefines a query using standard query syntax. This parameter is mandatory.q.opSpecifies the default operator for query expressions. Possible values are &#8220;AND&#8221; or &#8220;OR&#8221;.dfSpecifies a default searchable field.sowSplit on whitespace. If set to&nbsp;true, text analysis is invoked separately for each individual whitespace-separated term. The default is&nbsp;false; whitespace-separated term sequences will be provided to text analysis in one shot, enabling proper function of analysis filters that operate over term sequences, e.g., multi-word synonyms and shingles. Default parameter values are specified in&nbsp;solrconfig.xml, or overridden by query-time values in the request. Standard Query Parser Response By default, the response from the standard query parser contains one&nbsp;&lt;result&gt;&nbsp;block, which is unnamed. If the&nbsp;debug&nbsp;parameter&nbsp;is used, then an additional&nbsp;&lt;lst&gt;&nbsp;block will be returned, using the name &#8220;debug&#8221;. This will contain useful debugging info, including the original query string, the parsed query string, and explain info for each document in the &lt;result&gt; block. If the&nbsp;explainOther&nbsp;parameter&nbsp;is also used, then additional explain info will be provided for all the documents matching that query. Specifying Terms for the Standard Query Parser A query to the standard query parser is broken up into terms and operators. There are two types of terms: single terms and phrases. A single term is a single word such as &#8220;test&#8221; or &#8220;hello&#8221; A phrase is a group of words surrounded by double quotes such as &#8220;hello dolly&#8221; Term Modifiers Solr supports a variety of term modifiers that add flexibility or precision, as needed, to searches. These modifiers include wildcard characters, characters for making a search &#8220;fuzzy&#8221; or more general, and so on. The sections below describe these modifiers in detail. Wildcard Searches Solr\u2019s standard query parser supports single and multiple character wildcard searches within single terms. Wildcard characters can be applied to single terms, but not to search phrases. Wildcard Search Type Special Character Example Single character (matches a single character) ? The search string&nbsp;te?t&nbsp;would match both test and text. Multiple characters (matches zero or more sequential characters) * The wildcard search:&nbsp;tes*&nbsp;would match test, testing, and tester. You can also use wildcard characters in the middle of a term. For example:&nbsp;te*t&nbsp;would match test and text.&nbsp;*est&nbsp;would match pest and test. Fuzzy Searches Solr\u2019s standard query parser supports fuzzy searches based on the Damerau-Levenshtein Distance or Edit Distance algorithm. Fuzzy searches discover terms that are similar to a specified term without necessarily being an exact match. To perform a fuzzy search, use the tilde ~ symbol at the end of a single-word term. For example, to search for a term similar in spelling to &#8220;roam,&#8221; use the fuzzy search: roam~ This search will match terms like roams, foam, &amp; foams. It will also match the word &#8220;roam&#8221; itself. An optional distance parameter specifies the maximum number of edits allowed, between 0 and 2, defaulting to 2. For example: roam~1 This will match terms like roams &amp; foam &#8211; but not foams since it has an edit distance of &#8220;2&#8221; Proximity Searches A proximity search looks for terms that are within a specific distance from one another. To perform a proximity search, add the tilde character ~ and a numeric value to the end of a search phrase. For example, to search for a &#8220;apache&#8221; and &#8220;jakarta&#8221; within 10 words of each other in a document, use the search: &quot;jakarta apache&quot;~10 The distance referred to here is the number of term movements needed to match the specified phrase. In the example above, if &#8220;apache&#8221; and &#8220;jakarta&#8221; were 10 spaces apart in a field, but &#8220;apache&#8221; appeared before &#8220;jakarta&#8221;, more than 10 term movements would be required to move the terms together and position &#8220;apache&#8221; to the right of &#8220;jakarta&#8221; with a space in between. Existence Searches An existence search for a field matches all documents where a value exists for that field. To query for a field existing, simply use a wildcard instead of a term in the search. field:* A field will be considered to &#8220;exist&#8221; if it has any value, even values which are often considered &#8220;not existent&#8221;. (e.g.,&nbsp;NaN,&nbsp;&quot;&quot;, etc.) Range Searches A range search specifies a range of values for a field (a range with an upper bound and a lower bound). The query matches documents whose values for the specified field or fields fall within the range. Range queries can be inclusive or exclusive of the upper and lower bounds. Sorting is done lexicographically, except on numeric fields. For example, the range query below matches all documents whose&nbsp;popularity&nbsp;field has a value between 52 and 10,000, inclusive. popularity:[52 TO 10000] Range queries are not limited to date fields or even numerical fields. You could also use range queries with non-date fields: title:{Aida TO Carmen} This will find all documents whose titles are between Aida and Carmen, but not including Aida and Carmen. The brackets around a query determine its inclusiveness. Square brackets&nbsp;[&nbsp;&amp;&nbsp;]&nbsp;denote an inclusive range query that matches values including the upper and lower bound. Curly brackets&nbsp;{&nbsp;&amp;&nbsp;}&nbsp;denote an exclusive range query that matches values between the upper and lower bounds, but excluding the upper and lower bounds themselves. You can mix these types so one end of the range is inclusive and the other is exclusive. Here\u2019s an example:&nbsp;count:{1 TO 10] Wildcards,&nbsp;*, can also be used for either or both endpoints to specify an open-ended range query. This is a&nbsp;divergence from Lucene\u2019s Classic Query Parser. field:[* TO 100]&nbsp;finds all field values less than or equal to 100. field:[100 TO *]&nbsp;finds all field values greater than or equal to 100. field:[* TO *]&nbsp;finds any document with a [&hellip;]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/\" \/>\n<meta property=\"og:site_name\" content=\"Aeologic Blog\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/AeoLogicTech\/\" \/>\n<meta property=\"article:published_time\" content=\"2020-06-08T04:13:28+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2020-06-15T07:46:26+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2020\/06\/Standard-Query-in-solr.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1080\" \/>\n\t<meta property=\"og:image:height\" content=\"622\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Manoj Kumar\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@aeologictech\" \/>\n<meta name=\"twitter:site\" content=\"@aeologictech\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Manoj Kumar\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"9 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":[\"Article\",\"BlogPosting\"],\"@id\":\"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/\"},\"author\":{\"name\":\"Manoj Kumar\",\"@id\":\"https:\/\/www.aeologic.com\/blog\/#\/schema\/person\/13549984ba8e5f441cc733ed20d7daa4\"},\"headline\":\"The Standard Query Parser &#8211; Ultimate Solr Guide\",\"datePublished\":\"2020-06-08T04:13:28+00:00\",\"dateModified\":\"2020-06-15T07:46:26+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/\"},\"wordCount\":1696,\"publisher\":{\"@id\":\"https:\/\/www.aeologic.com\/blog\/#organization\"},\"image\":{\"@id\":\"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2020\/06\/Standard-Query-in-solr.png\",\"keywords\":[\"parser\",\"query parser\",\"Solr parser\",\"standard query parser\"],\"articleSection\":[\"Solr\"],\"inLanguage\":\"en-US\"},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/\",\"url\":\"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/\",\"name\":\"The Standard Query Parser - Ultimate Solr Guide - Aeologic Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.aeologic.com\/blog\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2020\/06\/Standard-Query-in-solr.png\",\"datePublished\":\"2020-06-08T04:13:28+00:00\",\"dateModified\":\"2020-06-15T07:46:26+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/#primaryimage\",\"url\":\"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2020\/06\/Standard-Query-in-solr.png\",\"contentUrl\":\"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2020\/06\/Standard-Query-in-solr.png\",\"width\":1080,\"height\":622},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.aeologic.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"The Standard Query Parser &#8211; Ultimate Solr Guide\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.aeologic.com\/blog\/#website\",\"url\":\"https:\/\/www.aeologic.com\/blog\/\",\"name\":\"Aeologic Blog\",\"description\":\"Aeologic\",\"publisher\":{\"@id\":\"https:\/\/www.aeologic.com\/blog\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.aeologic.com\/blog\/?s={search_term_string}\"},\"query-input\":\"required name=search_term_string\"}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/www.aeologic.com\/blog\/#organization\",\"name\":\"AeoLogic Technologies\",\"url\":\"https:\/\/www.aeologic.com\/blog\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.aeologic.com\/blog\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2022\/05\/new-logo-aeo.jpg\",\"contentUrl\":\"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2022\/05\/new-logo-aeo.jpg\",\"width\":385,\"height\":162,\"caption\":\"AeoLogic Technologies\"},\"image\":{\"@id\":\"https:\/\/www.aeologic.com\/blog\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/www.facebook.com\/AeoLogicTech\/\",\"https:\/\/x.com\/aeologictech\"]},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.aeologic.com\/blog\/#\/schema\/person\/13549984ba8e5f441cc733ed20d7daa4\",\"name\":\"Manoj Kumar\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.aeologic.com\/blog\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/24ce77602da5eb5715d74a95733f6c7548e2af73f5a493f9bc0bf55f611d025e?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/24ce77602da5eb5715d74a95733f6c7548e2af73f5a493f9bc0bf55f611d025e?s=96&d=mm&r=g\",\"caption\":\"Manoj Kumar\"},\"description\":\"Manoj Kumar is a seasoned Digital Marketing Manager and passionate Tech Blogger with deep expertise in SEO, AI trends, and emerging digital technologies. He writes about innovative solutions that drive growth and transformation across industry. Featured on - YOURSTORY | TECHSLING | ELEARNINGINDUSTRY | DATASCIENCECENTRAL | TIMESOFINDIA | MEDIUM | DATAFLOQ\",\"sameAs\":[\"https:\/\/www.aeologic.com\/\",\"https:\/\/www.linkedin.com\/in\/manoj-kumar-rajput\/\"],\"url\":\"https:\/\/www.aeologic.com\/blog\/author\/manoj\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"The Standard Query Parser - Ultimate Solr Guide - Aeologic Blog","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/","og_locale":"en_US","og_type":"article","og_title":"The Standard Query Parser - Ultimate Solr Guide - Aeologic Blog","og_description":"Solr\u2019s default Query Parser is also known as the \u201clucene\u201d parser. The key advantage of the standard query parser is that it supports a robust and fairly intuitive syntax allowing you to create a variety of structured queries. The largest disadvantage is that it\u2019s very intolerant of syntax errors, as compared with something like the&nbsp;DisMax&nbsp;query parser which is designed to throw as few errors as possible. Standard Query Parser Parameters In addition to the&nbsp;Common Query Parameters,&nbsp;Faceting Parameters,&nbsp;Highlighting Parameters, and&nbsp;MoreLikeThis Parameters, the standard query parser supports the parameters described in the table below.qDefines a query using standard query syntax. This parameter is mandatory.q.opSpecifies the default operator for query expressions. Possible values are &#8220;AND&#8221; or &#8220;OR&#8221;.dfSpecifies a default searchable field.sowSplit on whitespace. If set to&nbsp;true, text analysis is invoked separately for each individual whitespace-separated term. The default is&nbsp;false; whitespace-separated term sequences will be provided to text analysis in one shot, enabling proper function of analysis filters that operate over term sequences, e.g., multi-word synonyms and shingles. Default parameter values are specified in&nbsp;solrconfig.xml, or overridden by query-time values in the request. Standard Query Parser Response By default, the response from the standard query parser contains one&nbsp;&lt;result&gt;&nbsp;block, which is unnamed. If the&nbsp;debug&nbsp;parameter&nbsp;is used, then an additional&nbsp;&lt;lst&gt;&nbsp;block will be returned, using the name &#8220;debug&#8221;. This will contain useful debugging info, including the original query string, the parsed query string, and explain info for each document in the &lt;result&gt; block. If the&nbsp;explainOther&nbsp;parameter&nbsp;is also used, then additional explain info will be provided for all the documents matching that query. Specifying Terms for the Standard Query Parser A query to the standard query parser is broken up into terms and operators. There are two types of terms: single terms and phrases. A single term is a single word such as &#8220;test&#8221; or &#8220;hello&#8221; A phrase is a group of words surrounded by double quotes such as &#8220;hello dolly&#8221; Term Modifiers Solr supports a variety of term modifiers that add flexibility or precision, as needed, to searches. These modifiers include wildcard characters, characters for making a search &#8220;fuzzy&#8221; or more general, and so on. The sections below describe these modifiers in detail. Wildcard Searches Solr\u2019s standard query parser supports single and multiple character wildcard searches within single terms. Wildcard characters can be applied to single terms, but not to search phrases. Wildcard Search Type Special Character Example Single character (matches a single character) ? The search string&nbsp;te?t&nbsp;would match both test and text. Multiple characters (matches zero or more sequential characters) * The wildcard search:&nbsp;tes*&nbsp;would match test, testing, and tester. You can also use wildcard characters in the middle of a term. For example:&nbsp;te*t&nbsp;would match test and text.&nbsp;*est&nbsp;would match pest and test. Fuzzy Searches Solr\u2019s standard query parser supports fuzzy searches based on the Damerau-Levenshtein Distance or Edit Distance algorithm. Fuzzy searches discover terms that are similar to a specified term without necessarily being an exact match. To perform a fuzzy search, use the tilde ~ symbol at the end of a single-word term. For example, to search for a term similar in spelling to &#8220;roam,&#8221; use the fuzzy search: roam~ This search will match terms like roams, foam, &amp; foams. It will also match the word &#8220;roam&#8221; itself. An optional distance parameter specifies the maximum number of edits allowed, between 0 and 2, defaulting to 2. For example: roam~1 This will match terms like roams &amp; foam &#8211; but not foams since it has an edit distance of &#8220;2&#8221; Proximity Searches A proximity search looks for terms that are within a specific distance from one another. To perform a proximity search, add the tilde character ~ and a numeric value to the end of a search phrase. For example, to search for a &#8220;apache&#8221; and &#8220;jakarta&#8221; within 10 words of each other in a document, use the search: \"jakarta apache\"~10 The distance referred to here is the number of term movements needed to match the specified phrase. In the example above, if &#8220;apache&#8221; and &#8220;jakarta&#8221; were 10 spaces apart in a field, but &#8220;apache&#8221; appeared before &#8220;jakarta&#8221;, more than 10 term movements would be required to move the terms together and position &#8220;apache&#8221; to the right of &#8220;jakarta&#8221; with a space in between. Existence Searches An existence search for a field matches all documents where a value exists for that field. To query for a field existing, simply use a wildcard instead of a term in the search. field:* A field will be considered to &#8220;exist&#8221; if it has any value, even values which are often considered &#8220;not existent&#8221;. (e.g.,&nbsp;NaN,&nbsp;\"\", etc.) Range Searches A range search specifies a range of values for a field (a range with an upper bound and a lower bound). The query matches documents whose values for the specified field or fields fall within the range. Range queries can be inclusive or exclusive of the upper and lower bounds. Sorting is done lexicographically, except on numeric fields. For example, the range query below matches all documents whose&nbsp;popularity&nbsp;field has a value between 52 and 10,000, inclusive. popularity:[52 TO 10000] Range queries are not limited to date fields or even numerical fields. You could also use range queries with non-date fields: title:{Aida TO Carmen} This will find all documents whose titles are between Aida and Carmen, but not including Aida and Carmen. The brackets around a query determine its inclusiveness. Square brackets&nbsp;[&nbsp;&amp;&nbsp;]&nbsp;denote an inclusive range query that matches values including the upper and lower bound. Curly brackets&nbsp;{&nbsp;&amp;&nbsp;}&nbsp;denote an exclusive range query that matches values between the upper and lower bounds, but excluding the upper and lower bounds themselves. You can mix these types so one end of the range is inclusive and the other is exclusive. Here\u2019s an example:&nbsp;count:{1 TO 10] Wildcards,&nbsp;*, can also be used for either or both endpoints to specify an open-ended range query. This is a&nbsp;divergence from Lucene\u2019s Classic Query Parser. field:[* TO 100]&nbsp;finds all field values less than or equal to 100. field:[100 TO *]&nbsp;finds all field values greater than or equal to 100. field:[* TO *]&nbsp;finds any document with a [&hellip;]","og_url":"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/","og_site_name":"Aeologic Blog","article_publisher":"https:\/\/www.facebook.com\/AeoLogicTech\/","article_published_time":"2020-06-08T04:13:28+00:00","article_modified_time":"2020-06-15T07:46:26+00:00","og_image":[{"width":1080,"height":622,"url":"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2020\/06\/Standard-Query-in-solr.png","type":"image\/png"}],"author":"Manoj Kumar","twitter_card":"summary_large_image","twitter_creator":"@aeologictech","twitter_site":"@aeologictech","twitter_misc":{"Written by":"Manoj Kumar","Est. reading time":"9 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":["Article","BlogPosting"],"@id":"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/#article","isPartOf":{"@id":"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/"},"author":{"name":"Manoj Kumar","@id":"https:\/\/www.aeologic.com\/blog\/#\/schema\/person\/13549984ba8e5f441cc733ed20d7daa4"},"headline":"The Standard Query Parser &#8211; Ultimate Solr Guide","datePublished":"2020-06-08T04:13:28+00:00","dateModified":"2020-06-15T07:46:26+00:00","mainEntityOfPage":{"@id":"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/"},"wordCount":1696,"publisher":{"@id":"https:\/\/www.aeologic.com\/blog\/#organization"},"image":{"@id":"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/#primaryimage"},"thumbnailUrl":"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2020\/06\/Standard-Query-in-solr.png","keywords":["parser","query parser","Solr parser","standard query parser"],"articleSection":["Solr"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/","url":"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/","name":"The Standard Query Parser - Ultimate Solr Guide - Aeologic Blog","isPartOf":{"@id":"https:\/\/www.aeologic.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/#primaryimage"},"image":{"@id":"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/#primaryimage"},"thumbnailUrl":"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2020\/06\/Standard-Query-in-solr.png","datePublished":"2020-06-08T04:13:28+00:00","dateModified":"2020-06-15T07:46:26+00:00","breadcrumb":{"@id":"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/#primaryimage","url":"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2020\/06\/Standard-Query-in-solr.png","contentUrl":"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2020\/06\/Standard-Query-in-solr.png","width":1080,"height":622},{"@type":"BreadcrumbList","@id":"https:\/\/www.aeologic.com\/blog\/ultimate-solr-guide14-the-standard-query-parser\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.aeologic.com\/blog\/"},{"@type":"ListItem","position":2,"name":"The Standard Query Parser &#8211; Ultimate Solr Guide"}]},{"@type":"WebSite","@id":"https:\/\/www.aeologic.com\/blog\/#website","url":"https:\/\/www.aeologic.com\/blog\/","name":"Aeologic Blog","description":"Aeologic","publisher":{"@id":"https:\/\/www.aeologic.com\/blog\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.aeologic.com\/blog\/?s={search_term_string}"},"query-input":"required name=search_term_string"}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.aeologic.com\/blog\/#organization","name":"AeoLogic Technologies","url":"https:\/\/www.aeologic.com\/blog\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.aeologic.com\/blog\/#\/schema\/logo\/image\/","url":"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2022\/05\/new-logo-aeo.jpg","contentUrl":"https:\/\/www.aeologic.com\/blog\/wp-content\/uploads\/2022\/05\/new-logo-aeo.jpg","width":385,"height":162,"caption":"AeoLogic Technologies"},"image":{"@id":"https:\/\/www.aeologic.com\/blog\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/AeoLogicTech\/","https:\/\/x.com\/aeologictech"]},{"@type":"Person","@id":"https:\/\/www.aeologic.com\/blog\/#\/schema\/person\/13549984ba8e5f441cc733ed20d7daa4","name":"Manoj Kumar","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.aeologic.com\/blog\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/24ce77602da5eb5715d74a95733f6c7548e2af73f5a493f9bc0bf55f611d025e?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/24ce77602da5eb5715d74a95733f6c7548e2af73f5a493f9bc0bf55f611d025e?s=96&d=mm&r=g","caption":"Manoj Kumar"},"description":"Manoj Kumar is a seasoned Digital Marketing Manager and passionate Tech Blogger with deep expertise in SEO, AI trends, and emerging digital technologies. He writes about innovative solutions that drive growth and transformation across industry. Featured on - YOURSTORY | TECHSLING | ELEARNINGINDUSTRY | DATASCIENCECENTRAL | TIMESOFINDIA | MEDIUM | DATAFLOQ","sameAs":["https:\/\/www.aeologic.com\/","https:\/\/www.linkedin.com\/in\/manoj-kumar-rajput\/"],"url":"https:\/\/www.aeologic.com\/blog\/author\/manoj\/"}]}},"_links":{"self":[{"href":"https:\/\/www.aeologic.com\/blog\/wp-json\/wp\/v2\/posts\/1309","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.aeologic.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.aeologic.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.aeologic.com\/blog\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.aeologic.com\/blog\/wp-json\/wp\/v2\/comments?post=1309"}],"version-history":[{"count":0,"href":"https:\/\/www.aeologic.com\/blog\/wp-json\/wp\/v2\/posts\/1309\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.aeologic.com\/blog\/wp-json\/wp\/v2\/media\/1346"}],"wp:attachment":[{"href":"https:\/\/www.aeologic.com\/blog\/wp-json\/wp\/v2\/media?parent=1309"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.aeologic.com\/blog\/wp-json\/wp\/v2\/categories?post=1309"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.aeologic.com\/blog\/wp-json\/wp\/v2\/tags?post=1309"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}