StrField with Wildcard Search
Hello, There are quite a few links that detail the difference between StrField and TextField. Also links that explain that, even though the field is indexed, it is not tokenized and stored as a single keyword, as can be verified by the debug analysis on Solr admin and CURL debugQuery options. What I am unable to understand is how a wildcard works on StrFields? For example, if the name is "John Doe" and I search for "John*", I get that match. Which means, that somewhere deep within, maybe a Trie or Dictionary representation exists that allows this search with a partial string. I would have assumed that wildcard would match on TextFields which allow (Edge)NGramFilters, etc. -- SRK
Re: StrField with Wildcard Search
Hi, Okay. So it seems that the wildcard searches will perform a (sort-of) dictionary search where they will inspect every (full keyword) token at search time, and do a match instead of a match on pre-created index-time tokens with TextField. However, the wildcard/fuzzy functionality will still be provided no matter the approach... SRK On Thursday, September 8, 2016 5:05 PM, Ahmet Arslan wrote: Hi, EdgeNGram and Wildcard may be used to achieve the same goal: prefix search or starts with search. Lets say, wildcard enumerates the whole inverted index, thus it may get slower for very large databases. With this one no index time manipulation is required. EdgeNGram does its magic at index time, indexes a lot of tokens, all possible prefixes. Index size gets bigger, query time no wildcard operator required in this one. Ahmet On Thursday, September 8, 2016 12:35 PM, Sandeep Khanzode wrote: Hello, There are quite a few links that detail the difference between StrField and TextField. Also links that explain that, even though the field is indexed, it is not tokenized and stored as a single keyword, as can be verified by the debug analysis on Solr admin and CURL debugQuery options. What I am unable to understand is how a wildcard works on StrFields? For example, if the name is "John Doe" and I search for "John*", I get that match. Which means, that somewhere deep within, maybe a Trie or Dictionary representation exists that allows this search with a partial string. I would have assumed that wildcard would match on TextFields which allow (Edge)NGramFilters, etc. -- SRK
Custom Function-based Fields
Hi, Can someone please direct me to some documentation that shows how to do this ... ? I need to write a non-trivial function that will return a new custom (not in schema) field but which is more complicated than a simple sum/avg/etc. I want to create a function that looks at a few dateranges in the current records and return possible an enum or an integer ... Maybe something similar could also be helpful ... Thanks. SRK
Solr DateRange Query with AND and different op types
Hi,
Can I not query like this?
{!field f=schedule1 op=Contains}[1988-10-22T18:30:00Z TO *] AND
-schedule3:[1988-10-22T18:30:00Z TO *] AND -schedule2:[1988-10-22T18:30:00Z TO
*] I keep getting parsing and date math related errors.
If I change it to ...schedule1:[1988-10-22T18:30:00Z TO *] AND
-schedule3:[1988-10-22T18:30:00Z TO *] AND -schedule2:[1988-10-22T18:30:00Z TO
*]
... this works. But then I obviously have the functionality wrong (intersects
is the default).
Can I not mix and match multiple op types (like contains, within, intersects)
in a AND/OR joined query?
SRK
Re: Solr DateRange Query with AND and different op types
Hi, Can someone please reply to my query? Let me know if it is not
understandable. Thanks.
SRK
On Monday, September 19, 2016 6:00 PM, Sandeep Khanzode
wrote:
Hi,
Can I not query like this?
{!field f=schedule1 op=Contains}[1988-10-22T18:30:00Z TO *] AND
-schedule3:[1988-10-22T18:30:00Z TO *] AND -schedule2:[1988-10-22T18:30:00Z TO
*] I keep getting parsing and date math related errors.
If I change it to ...schedule1:[1988-10-22T18:30:00Z TO *] AND
-schedule3:[1988-10-22T18:30:00Z TO *] AND -schedule2:[1988-10-22T18:30:00Z TO
*]
... this works. But then I obviously have the functionality wrong (intersects
is the default).
Can I not mix and match multiple op types (like contains, within, intersects)
in a AND/OR joined query?
SRK
How to set NOT clause on Date range query in Solr
Have been trying to understand this for a while ...How can I specify NOT clause
in the following query?{!field f=schedule op=Intersects}[2016-08-26T12:30:00Z
TO 2016-08-26T18:30:00Z]{!field f=schedule op=Contains}[2016-08-26T12:30:00Z TO
2016-08-26T18:30:00Z]Like, without LocalParams, we can specify
-DateField:[2016-08-26T12:30:00Z TO 2016-08-26T18:30:00Z] to get an equivalent
NOT clause. But, I need a NOT Contains Date Range query.I have tried a few
options but I end up getting parsing errors. Surely there must be some obvious
way I am missing. SRK
Negative Date Query for Local Params in Solr
For Solr 6.1.0
This works .. -{!field f=schedule op=Intersects}2016-08-26T12:00:56Z
This works .. {!field f=schedule op=Contains}[2016-08-26T12:00:12Z TO
2016-08-26T15:00:12Z]
Why does this not work?-{!field f=schedule op=Contains}[2016-08-26T12:00:12Z TO
2016-08-26T15:00:12Z]
SRK
Re: Negative Date Query for Local Params in Solr
This is what I get ...
{ "responseHeader": { "status": 400, "QTime": 1, "params": { "q": "-{!field
f=schedule op=Contains}[2016-08-26T12:00:12Z TO 2016-08-26T15:00:12Z]",
"indent": "true", "wt": "json", "_": "1474373612202" } }, "error": { "msg":
"Invalid Date in Date Math String:'[2016-08-26T12:00:12Z'", "code": 400 }}
SRK
On Tuesday, September 20, 2016 5:34 PM, David Smiley
wrote:
It should, I think... what happens? Can you ascertain the nature of the
results?
~ David
On Tue, Sep 20, 2016 at 5:35 AM Sandeep Khanzode
wrote:
> For Solr 6.1.0
> This works .. -{!field f=schedule op=Intersects}2016-08-26T12:00:56Z
>
> This works .. {!field f=schedule op=Contains}[2016-08-26T12:00:12Z TO
> 2016-08-26T15:00:12Z]
>
>
> Why does this not work?-{!field f=schedule
> op=Contains}[2016-08-26T12:00:12Z TO 2016-08-26T15:00:12Z]
> SRK
--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com
Re: Negative Date Query for Local Params in Solr
Wow. Simply awesome!
Where can I read more about this? I am not sure whether I understand what is
going on behind the scenes ... like which parser is invoked for !field, how can
we know which all special local params exist, whether we should prefer edismax
over others, when is the LuceneQParser invoked in other conditions, etc? Would
appreciate if you could indicate some references to catch up.
Thanks a lot ... SRK
Show original message On Tuesday, September 20, 2016 5:54 PM, David
Smiley wrote:
OH! Ok the moment the query no longer starts with "{!", the query is
parsed by defType (for 'q') and will default to lucene QParser. So then it
appears we have a clause with a NOT operator. In this parsing mode,
embedded "{!" terminates at the "}". This means you can't put the
sub-query text after the "}", you instead need to put it in the special "v"
local-param. e.g.:
-{!field f=schedule op=Contains v='[2016-08-26T12:00:12Z TO
2016-08-26T15:00:12Z]'}
On Tue, Sep 20, 2016 at 8:15 AM Sandeep Khanzode
wrote:
> This is what I get ...
> { "responseHeader": { "status": 400, "QTime": 1, "params": { "q":
> "-{!field f=schedule op=Contains}[2016-08-26T12:00:12Z TO
> 2016-08-26T15:00:12Z]", "indent": "true", "wt": "json", "_":
> "1474373612202" } }, "error": { "msg": "Invalid Date in Date Math
> String:'[2016-08-26T12:00:12Z'", "code": 400 }}
> SRK
>
> On Tuesday, September 20, 2016 5:34 PM, David Smiley <
> david.w.smi...@gmail.com> wrote:
>
>
> It should, I think... what happens? Can you ascertain the nature of the
> results?
> ~ David
>
> On Tue, Sep 20, 2016 at 5:35 AM Sandeep Khanzode
> wrote:
>
> > For Solr 6.1.0
> > This works .. -{!field f=schedule op=Intersects}2016-08-26T12:00:56Z
> >
> > This works .. {!field f=schedule op=Contains}[2016-08-26T12:00:12Z TO
> > 2016-08-26T15:00:12Z]
> >
> >
> > Why does this not work?-{!field f=schedule
> > op=Contains}[2016-08-26T12:00:12Z TO 2016-08-26T15:00:12Z]
> > SRK
>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
>
>
--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com
JSON Facet API
Hello,
How can I specify JSON Facets in SolrJ? The below facet query for example ...
&json.facet={
facet1: {
type: query,
q: "field1:value1 AND field2:value2",
facet:
{
facet1sub1: {
type: query,
q: "{!field f=mydate op=Intersects}2016-09-08T08:00:00",
facet:
{
id:
{
type: terms,
field: id
}
}
},
facet1sub2: {
type: query,
q: "-{!field f=myseconddate op=Intersects}2016-09-08T08:00:00 AND -{!field
f=mydateop=Intersects}2016-05-08T08:00:00",
facet:
{
id:
{
type: terms,
field: id
}
}
}
}
}
},
SRK
Re: Negative Date Query for Local Params in Solr
Thanks, David! Perhaps browsing the Solr sources may be a necessity at some
point in time. :) SRK
On Wednesday, September 21, 2016 9:08 AM, David Smiley
wrote:
So that page referenced describes local-params, and describes the special
"v" local-param. But first, see a list of all query parsers (which lists
"field"): https://cwiki.apache.org/confluence/display/solr/Other+Parsers
and
https://cwiki.apache.org/confluence/display/solr/The+Standard+Query+Parser for
the "lucene" one.
The "op" param is rather unique... it's not defined by any query parser. A
trick is done in which a custom field type (DateRangeField in this case) is
able to inspect the local-params, and thus define and use params it needs.
https://cwiki.apache.org/confluence/display/solr/Working+with+Dates "More
DateRangeField Details" mentions "op". {!lucene df=dateRange
op=Contains}... would also work. I don't know of any other local-param
used in this way.
On Tue, Sep 20, 2016 at 11:21 PM David Smiley
wrote:
> Personally I learned this by pouring over Solr's source code some time
> ago. I suppose the only official reference to this stuff is:
>
> https://cwiki.apache.org/confluence/display/solr/Local+Parameters+in+Queries
> But that page doesn't address the implications for when the syntax is a
> clause of a larger query instead of being the whole query (i.e. has "{!"...
> but but not at the first char).
>
> On Tue, Sep 20, 2016 at 2:06 PM Sandeep Khanzode
> wrote:
>
>> Wow. Simply awesome!
>> Where can I read more about this? I am not sure whether I understand what
>> is going on behind the scenes ... like which parser is invoked for !field,
>> how can we know which all special local params exist, whether we should
>> prefer edismax over others, when is the LuceneQParser invoked in other
>> conditions, etc? Would appreciate if you could indicate some references to
>> catch up.
>> Thanks a lot ... SRK
>>
>> Show original message On Tuesday, September 20, 2016 5:54 PM, David
>> Smiley wrote:
>>
>>
>> OH! Ok the moment the query no longer starts with "{!", the query is
>> parsed by defType (for 'q') and will default to lucene QParser. So then
>> it
>> appears we have a clause with a NOT operator. In this parsing mode,
>> embedded "{!" terminates at the "}". This means you can't put the
>> sub-query text after the "}", you instead need to put it in the special
>> "v"
>> local-param. e.g.:
>> -{!field f=schedule op=Contains v='[2016-08-26T12:00:12Z TO
>> 2016-08-26T15:00:12Z]'}
>>
>> On Tue, Sep 20, 2016 at 8:15 AM Sandeep Khanzode
>> wrote:
>>
>> > This is what I get ...
>> > { "responseHeader": { "status": 400, "QTime": 1, "params": { "q":
>> > "-{!field f=schedule op=Contains}[2016-08-26T12:00:12Z TO
>> > 2016-08-26T15:00:12Z]", "indent": "true", "wt": "json", "_":
>> > "1474373612202" } }, "error": { "msg": "Invalid Date in Date Math
>> > String:'[2016-08-26T12:00:12Z'", "code": 400 }}
>> > SRK
>> >
>> > On Tuesday, September 20, 2016 5:34 PM, David Smiley <
>> > david.w.smi...@gmail.com> wrote:
>> >
>> >
>> > It should, I think... what happens? Can you ascertain the nature of the
>> > results?
>> > ~ David
>> >
>> > On Tue, Sep 20, 2016 at 5:35 AM Sandeep Khanzode
>> > wrote:
>> >
>> > > For Solr 6.1.0
>> > > This works .. -{!field f=schedule op=Intersects}2016-08-26T12:00:56Z
>> > >
>> > > This works .. {!field f=schedule op=Contains}[2016-08-26T12:00:12Z TO
>> > > 2016-08-26T15:00:12Z]
>> > >
>> > >
>> > > Why does this not work?-{!field f=schedule
>> > > op=Contains}[2016-08-26T12:00:12Z TO 2016-08-26T15:00:12Z]
>> > > SRK
>> >
>> > --
>> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> > LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> > http://www.solrenterprisesearchserver.com
>> >
>> >
>> >
>>
>> --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>>
>>
>>
>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com
Re: JSON Facet API
Thanks a lot, Bram. I will try that ... SRK
On Wednesday, September 21, 2016 11:57 AM, Bram Van Dam
wrote:
On 21/09/16 05:40, Sandeep Khanzode wrote:
> How can I specify JSON Facets in SolrJ? The below facet query for example ...
SolrQuery query = new SolrQuery();
query.add("json.facet", jsonStringGoesHere);
- Bram
-field1:value1 OR field2:value2
Hi, If I query for -field1=value1 ... I get, say, 100 records and if I query for field2:value2 ... I may get 200 records I would assume that if I query for -field1:value1 OR field2:value2 ... I should get atleast 100 records (assuming they overlap, if not, upto 300 records). I am assuming that the default joining is OR. But I do not ... The result is that I get less than 100. If I didn't know better, I would have said that an AND is being done. I am expecting records that EITHER do NOT contain field1:value1 OR which contain field2:value2. Please let me know what I am missing. Thanks. SRK
Re: -field1:value1 OR field2:value2
Yup. That works. So does (*:* NOT ...) Thanks, Alex. SRK On Monday, September 26, 2016 3:03 PM, Alexandre Rafalovitch wrote: Try field2:value2 OR (*:* -field1=value1) There is a magic in negative query syntax that breaks down when it gets more complex. It's been discussed on the mailing list a bunch of times, though the discussions are hard to find by title. Regards, Alex. Newsletter and resources for Solr beginners and intermediates: http://www.solr-start.com/ On 26 September 2016 at 16:06, Sandeep Khanzode wrote: > Hi, > If I query for > -field1=value1 ... I get, say, 100 records > and if I query for > field2:value2 ... I may get 200 records > > I would assume that if I query for > -field1:value1 OR field2:value2 > > ... I should get atleast 100 records (assuming they overlap, if not, upto 300 > records). I am assuming that the default joining is OR. > But I do not ... > The result is that I get less than 100. If I didn't know better, I would have > said that an AND is being done. > > I am expecting records that EITHER do NOT contain field1:value1 OR which > contain field2:value2. > > Please let me know what I am missing. Thanks. > > SRK
Re: -field1:value1 OR field2:value2
Hi Alex, It seems that this is not an issue with AND clause. For example, if I do ... field1:value1 AND -field2:value2 ... the results seem to be an intersection of both. Is this an issue with OR? Which is which we replace it with an implicit (*:* NOT)? SRK On Monday, September 26, 2016 3:09 PM, Sandeep Khanzode wrote: Yup. That works. So does (*:* NOT ...) Thanks, Alex. SRK On Monday, September 26, 2016 3:03 PM, Alexandre Rafalovitch wrote: Try field2:value2 OR (*:* -field1=value1) There is a magic in negative query syntax that breaks down when it gets more complex. It's been discussed on the mailing list a bunch of times, though the discussions are hard to find by title. Regards, Alex. Newsletter and resources for Solr beginners and intermediates: http://www.solr-start.com/ On 26 September 2016 at 16:06, Sandeep Khanzode wrote: > Hi, > If I query for > -field1=value1 ... I get, say, 100 records > and if I query for > field2:value2 ... I may get 200 records > > I would assume that if I query for > -field1:value1 OR field2:value2 > > ... I should get atleast 100 records (assuming they overlap, if not, upto 300 > records). I am assuming that the default joining is OR. > But I do not ... > The result is that I get less than 100. If I didn't know better, I would have > said that an AND is being done. > > I am expecting records that EITHER do NOT contain field1:value1 OR which > contain field2:value2. > > Please let me know what I am missing. Thanks. > > SRK
Re: -field1:value1 OR field2:value2
Sure. Noted. Thanks for the link ... SRK On Monday, September 26, 2016 8:29 PM, Erick Erickson wrote: Please do not cross post to multiple lists, it's considered bad etiquette. Solr does not implement strict boolean logic, please read: https://lucidworks.com/blog/2011/12/28/why-not-and-or-and-not/ Best, Erick On Mon, Sep 26, 2016 at 2:58 AM, Alexandre Rafalovitch wrote: > I don't remember specifically :-(. Search the archives > http://search-lucene.com/ or follow-up on Solr Users list. Remember to > mention the version of Solr, as there were some bugs/features/fixes > with OR, I think. > > Regards, > Alex. > > Newsletter and resources for Solr beginners and intermediates: > http://www.solr-start.com/ > > > On 26 September 2016 at 16:56, Sandeep Khanzode > wrote: >> Hi Alex, >> It seems that this is not an issue with AND clause. For example, if I do ... >> field1:value1 AND -field2:value2 >> ... the results seem to be an intersection of both. >> Is this an issue with OR? Which is which we replace it with an implicit (*:* >> NOT)? SRK >> >> On Monday, September 26, 2016 3:09 PM, Sandeep Khanzode >> wrote: >> >> >> Yup. That works. So does (*:* NOT ...) >> Thanks, Alex. SRK >> >> On Monday, September 26, 2016 3:03 PM, Alexandre Rafalovitch >> wrote: >> >> >> Try field2:value2 OR (*:* -field1=value1) >> >> There is a magic in negative query syntax that breaks down when it >> gets more complex. It's been discussed on the mailing list a bunch of >> times, though the discussions are hard to find by title. >> >> Regards, >> Alex. >> >> Newsletter and resources for Solr beginners and intermediates: >> http://www.solr-start.com/ >> >> >> On 26 September 2016 at 16:06, Sandeep Khanzode >> wrote: >>> Hi, >>> If I query for >>> -field1=value1 ... I get, say, 100 records >>> and if I query for >>> field2:value2 ... I may get 200 records >>> >>> I would assume that if I query for >>> -field1:value1 OR field2:value2 >>> >>> ... I should get atleast 100 records (assuming they overlap, if not, upto >>> 300 records). I am assuming that the default joining is OR. >>> But I do not ... >>> The result is that I get less than 100. If I didn't know better, I would >>> have said that an AND is being done. >>> >>> I am expecting records that EITHER do NOT contain field1:value1 OR which >>> contain field2:value2. >>> >>> Please let me know what I am missing. Thanks. >>> >>> SRK >> >> >> >> >>
Wildcard searches with space in TextField/StrField
Hi, How does a search like abc* work in StrField. Since the entire thing is stored as a single token, is it a type of a trie structure that allows such wildcard matching? How can searches with space like 'a b*' be executed for text fields (tokenized on whitespace)? If we specify this type of query, it is broken down into two queries with field:a and field:b*. I would like them to be contiguous, sort of, like a phrase search with wild card. SRK
Re: Wildcard searches with space in TextField/StrField
Hi Erick, Reth, The 'a\ b*' as well as the q.op=AND approach worked (successfully) only for StrField for me. Any attempt at creating a 'a\ b*' for a TextField does not match any documents. The parsedQuery in debug mode does show 'field:a b*'. I am sure there are documents that should match. Another (maybe unrelated) observation is if I have 'field:a\ b', then the parsedQuery is field:a field:b. Which does not match as expected (matches individually). Can you please provide an example that I can use in Solr Query dashboard? That will be helpful. I have also seen that wildcard queries work irrespective of field type i.e. StrField as well as TextField. That makes sense because with a WhitespaceTokenizer only creates word boundaries when we do not use a EdgeNGramFilter. If I am not wrong, that is. SRK On Friday, November 11, 2016 5:00 AM, Erick Erickson wrote: You can escape the space with a backslash as 'a\ b*' Best, Erick On Thu, Nov 10, 2016 at 2:37 PM, Reth RM wrote: > I don't think you can do wildcard on StrField. For text field, if your > query is "category:(test m*)" the parsed query will be "category:test OR > category:m*" > You can add q.op=AND to make an AND between those terms. > > For phrase type wild card query support, as per docs, it > is ComplexPhraseQueryParser that supports it. (I haven't tested it myself) > > https://cwiki.apache.org/confluence/display/solr/Other+Parsers#OtherParsers-ComplexPhraseQueryParser > > On Thu, Nov 10, 2016 at 11:40 AM, Sandeep Khanzode < > sandeep_khanz...@yahoo.com.invalid> wrote: > >> Hi, >> How does a search like abc* work in StrField. Since the entire thing is >> stored as a single token, is it a type of a trie structure that allows such >> wildcard matching? >> How can searches with space like 'a b*' be executed for text fields >> (tokenized on whitespace)? If we specify this type of query, it is broken >> down into two queries with field:a and field:b*. I would like them to be >> contiguous, sort of, like a phrase search with wild card. >> SRK
Re: Wildcard searches with space in TextField/StrField
Thanks, Erick. I am actually not trying to use the String field (prefer a TextField here). But, in my comparisons with TextField, it seems that something like phrase matching with whitespace and wildcard (like, 'my do*' or say, 'my dog*', or say, 'my dog has*') can only be accomplished with a string type field, especially because, with a WhitespaceTokenizer in TextField, the space will be lost, and all tokens will be individually considered. Am I missing something? SRK On Friday, November 11, 2016 10:05 PM, Erick Erickson wrote: You have to query text and string fields differently, that's just the way it works. The problem is getting the query string through the parser as a _single_ token or as multiple tokens. Let's say you have a string field with the "a b" example. You have a single token a b that starts at offset 0. But with a text field, you have two tokens, a at position 0 b at position 1 But when the query parser sees "a b" (without quotes) it splits it into two tokens, and only the text field has both tokens so the string field won't match. OTOH, when the query parser sees "a\ b" it passes this through as a single token, which only matches the string field as there's no _single_ token "a b" in the text field. But a more interesting question is why you want to search this way. String fields are intended for keywords, machine-generated IDs and the like. They're pretty useless for searching anything except 1> exact tokens 2> prefixes While if you have "my dog has fleas" in a string field, you _can_ search "*dog*" and get a hit but the performance is poor when you get a large corpus. Performance for "my*" will be pretty good though. In all this sounds like an XY problem, what's the use-case you're trying to solve? Best, Erick On Thu, Nov 10, 2016 at 10:11 PM, Sandeep Khanzode wrote: > Hi Erick, Reth, > > The 'a\ b*' as well as the q.op=AND approach worked (successfully) only for > StrField for me. > > Any attempt at creating a 'a\ b*' for a TextField does not match any > documents. The parsedQuery in debug mode does show 'field:a b*'. I am sure > there are documents that should match. > Another (maybe unrelated) observation is if I have 'field:a\ b', then the > parsedQuery is field:a field:b. Which does not match as expected (matches > individually). > > Can you please provide an example that I can use in Solr Query dashboard? > That will be helpful. > > I have also seen that wildcard queries work irrespective of field type i.e. > StrField as well as TextField. That makes sense because with a > WhitespaceTokenizer only creates word boundaries when we do not use a > EdgeNGramFilter. If I am not wrong, that is. SRK > > On Friday, November 11, 2016 5:00 AM, Erick Erickson > wrote: > > > You can escape the space with a backslash as 'a\ b*' > > Best, > Erick > > On Thu, Nov 10, 2016 at 2:37 PM, Reth RM wrote: >> I don't think you can do wildcard on StrField. For text field, if your >> query is "category:(test m*)" the parsed query will be "category:test OR >> category:m*" >> You can add q.op=AND to make an AND between those terms. >> >> For phrase type wild card query support, as per docs, it >> is ComplexPhraseQueryParser that supports it. (I haven't tested it myself) >> >> https://cwiki.apache.org/confluence/display/solr/Other+Parsers#OtherParsers-ComplexPhraseQueryParser >> >> On Thu, Nov 10, 2016 at 11:40 AM, Sandeep Khanzode < >> sandeep_khanz...@yahoo.com.invalid> wrote: >> >>> Hi, >>> How does a search like abc* work in StrField. Since the entire thing is >>> stored as a single token, is it a type of a trie structure that allows such >>> wildcard matching? >>> How can searches with space like 'a b*' be executed for text fields >>> (tokenized on whitespace)? If we specify this type of query, it is broken >>> down into two queries with field:a and field:b*. I would like them to be >>> contiguous, sort of, like a phrase search with wild card. >>> SRK > > >
Re: Wildcard searches with space in TextField/StrField
Hi Erick,
I gave this a try.
These are my results. There is a record with "John D. Smith", and another named
"John Doe".
1.] {!complexphrase inOrder=true}name:"John D.*" ... does not fetch any
results.
2.] {!complexphrase inOrder=true}name:"John D*" ... fetches both results.
Second observation: There is a record with "John D Smith"
1.] {!complexphrase inOrder=true}name:"John*" ... does not fetch any results.
2.] {!complexphrase inOrder=true}name:"John D*" ... fetches that record.
3.] {!complexphrase inOrder=true}name:"John D S*" ... fetches that record.
SRK
On Sunday, November 13, 2016 7:43 AM, Erick Erickson
wrote:
Right, for that kind of use case you want complexPhraseQueryParser,
see:
https://cwiki.apache.org/confluence/display/solr/Other+Parsers#OtherParsers-ComplexPhraseQueryParser
Best,
Erick
On Sat, Nov 12, 2016 at 9:39 AM, Sandeep Khanzode
wrote:
> Thanks, Erick.
>
> I am actually not trying to use the String field (prefer a TextField here).
> But, in my comparisons with TextField, it seems that something like phrase
> matching with whitespace and wildcard (like, 'my do*' or say, 'my dog*', or
> say, 'my dog has*') can only be accomplished with a string type field,
> especially because, with a WhitespaceTokenizer in TextField, the space will
> be lost, and all tokens will be individually considered. Am I missing
> something?
>
> SRK
>
>
> On Friday, November 11, 2016 10:05 PM, Erick Erickson
> wrote:
>
>
> You have to query text and string fields differently, that's just the
> way it works. The problem is getting the query string through the
> parser as a _single_ token or as multiple tokens.
>
> Let's say you have a string field with the "a b" example. You have a
> single token
> a b that starts at offset 0.
>
> But with a text field, you have two tokens,
> a at position 0
> b at position 1
>
> But when the query parser sees "a b" (without quotes) it splits it
> into two tokens, and only the text field has both tokens so the string
> field won't match.
>
> OTOH, when the query parser sees "a\ b" it passes this through as a
> single token, which only matches the string field as there's no
> _single_ token "a b" in the text field.
>
> But a more interesting question is why you want to search this way.
> String fields are intended for keywords, machine-generated IDs and the
> like. They're pretty useless for searching anything except
> 1> exact tokens
> 2> prefixes
>
> While if you have "my dog has fleas" in a string field, you _can_
> search "*dog*" and get a hit but the performance is poor when you get
> a large corpus. Performance for "my*" will be pretty good though.
>
> In all this sounds like an XY problem, what's the use-case you're
> trying to solve?
>
> Best,
> Erick
>
>
>
> On Thu, Nov 10, 2016 at 10:11 PM, Sandeep Khanzode
> wrote:
>> Hi Erick, Reth,
>>
>> The 'a\ b*' as well as the q.op=AND approach worked (successfully) only
>> for StrField for me.
>>
>> Any attempt at creating a 'a\ b*' for a TextField does not match any
>> documents. The parsedQuery in debug mode does show 'field:a b*'. I am sure
>> there are documents that should match.
>> Another (maybe unrelated) observation is if I have 'field:a\ b', then the
>> parsedQuery is field:a field:b. Which does not match as expected (matches
>> individually).
>>
>> Can you please provide an example that I can use in Solr Query dashboard?
>> That will be helpful.
>>
>> I have also seen that wildcard queries work irrespective of field type
>> i.e. StrField as well as TextField. That makes sense because with a
>> WhitespaceTokenizer only creates word boundaries when we do not use a
>> EdgeNGramFilter. If I am not wrong, that is. SRK
>>
>> On Friday, November 11, 2016 5:00 AM, Erick Erickson
>> wrote:
>>
>>
>> You can escape the space with a backslash as 'a\ b*'
>>
>> Best,
>> Erick
>>
>> On Thu, Nov 10, 2016 at 2:37 PM, Reth RM wrote:
>>> I don't think you can do wildcard on StrField. For text field, if your
>>> query is "category:(test m*)" the parsed query will be "category:test
>>> OR
>>> category:m*"
>>> You can add q.op=AND to make an AND between those terms.
>>>
>>> For phrase type wild card query support, as per docs, it
>>> is ComplexPhraseQueryParser that supports it. (I haven't
Query parser behavior with AND and negative clause
Hi,
I have a simple query that should intersect with dateRange1 and NOT be
contained within dateRange2. I have tried the following options:
WORKS:
+{!field f=dateRange1 op=Intersects v='[2016-11-22T12:01:00Z TO
2016-11-22T13:59:00Z]'} +(*:* -{!field f=dateRange2 op=Contains
v='[2016-11-22T12:01:00Z TO 2016-11-22T13:59:00Z]'})
DOES NOT WORK :
{!field f=dateRange1 op=Intersects v='[2016-11-22T12:01:00Z TO
2016-11-22T13:59:00Z]'} AND (*:* -{!field f=dateRange2 op=Contains
v='[2016-11-22T12:01:00Z TO 2016-11-22T13:59:00Z]'})
Why?
WILL NOT WORK (because of the negative clause at the top level?):
{!field f=dateRange1 op=Intersects v='[2016-11-22T12:01:00Z TO
2016-11-22T13:59:00Z]'} AND -{!field f=dateRange2 op=Contains
v='[2016-11-22T12:01:00Z TO 2016-11-22T13:59:00Z]'}
SRK
Re: Wildcard searches with space in TextField/StrField
Hi,
This is the typical TextField with ...
SRK
On Thursday, November 24, 2016 1:38 AM, Reth RM
wrote:
what is the fieldType of those records?
On Tue, Nov 22, 2016 at 4:18 AM, Sandeep Khanzode
wrote:
Hi Erick,
I gave this a try.
These are my results. There is a record with "John D. Smith", and another named
"John Doe".
1.] {!complexphrase inOrder=true}name:"John D.*" ... does not fetch any
results.
2.] {!complexphrase inOrder=true}name:"John D*" ... fetches both results.
Second observation: There is a record with "John D Smith"
1.] {!complexphrase inOrder=true}name:"John*" ... does not fetch any results.
2.] {!complexphrase inOrder=true}name:"John D*" ... fetches that record.
3.] {!complexphrase inOrder=true}name:"John D S*" ... fetches that record.
SRK
On Sunday, November 13, 2016 7:43 AM, Erick Erickson
wrote:
Right, for that kind of use case you want complexPhraseQueryParser,
see: https://cwiki.apache.org/ confluence/display/solr/Other+
Parsers#OtherParsers- ComplexPhraseQueryParser
Best,
Erick
On Sat, Nov 12, 2016 at 9:39 AM, Sandeep Khanzode
wrote:
> Thanks, Erick.
>
> I am actually not trying to use the String field (prefer a TextField here).
> But, in my comparisons with TextField, it seems that something like phrase
> matching with whitespace and wildcard (like, 'my do*' or say, 'my dog*', or
> say, 'my dog has*') can only be accomplished with a string type field,
> especially because, with a WhitespaceTokenizer in TextField, the space will
> be lost, and all tokens will be individually considered. Am I missing
> something?
>
> SRK
>
>
> On Friday, November 11, 2016 10:05 PM, Erick Erickson
> wrote:
>
>
> You have to query text and string fields differently, that's just the
> way it works. The problem is getting the query string through the
> parser as a _single_ token or as multiple tokens.
>
> Let's say you have a string field with the "a b" example. You have a
> single token
> a b that starts at offset 0.
>
> But with a text field, you have two tokens,
> a at position 0
> b at position 1
>
> But when the query parser sees "a b" (without quotes) it splits it
> into two tokens, and only the text field has both tokens so the string
> field won't match.
>
> OTOH, when the query parser sees "a\ b" it passes this through as a
> single token, which only matches the string field as there's no
> _single_ token "a b" in the text field.
>
> But a more interesting question is why you want to search this way.
> String fields are intended for keywords, machine-generated IDs and the
> like. They're pretty useless for searching anything except
> 1> exact tokens
> 2> prefixes
>
> While if you have "my dog has fleas" in a string field, you _can_
> search "*dog*" and get a hit but the performance is poor when you get
> a large corpus. Performance for "my*" will be pretty good though.
>
> In all this sounds like an XY problem, what's the use-case you're
> trying to solve?
>
> Best,
> Erick
>
>
>
> On Thu, Nov 10, 2016 at 10:11 PM, Sandeep Khanzode
> wrote:
>> Hi Erick, Reth,
>>
>> The 'a\ b*' as well as the q.op=AND approach worked (successfully) only
>> for StrField for me.
>>
>> Any attempt at creating a 'a\ b*' for a TextField does not match any
>> documents. The parsedQuery in debug mode does show 'field:a b*'. I am sure
>> there are documents that should match.
>> Another (maybe unrelated) observation is if I have 'field:a\ b', then the
>> parsedQuery is field:a field:b. Which does not match as expected (matches
>> individually).
>>
>> Can you please provide an example that I can use in Solr Query dashboard?
>> That will be helpful.
>>
>> I have also seen that wildcard queries work irrespective of field type
>> i.e. StrField as well as TextField. That makes sense because with a
>> WhitespaceTokenizer only creates word boundaries when we do not use a
>> EdgeNGramFilter. If I am not wrong, that is. SRK
>>
>> On Friday, November 11, 2016 5:00 AM, Erick Erickson
>> wrote:
>>
>>
>> You can escape the space with a backslash as 'a\ b*'
>>
>> Best,
>> Erick
>>
>> On Thu, Nov 10, 2016 at 2:37 PM, Reth RM wrote:
>>> I don't think you can do wildcard on StrField. For text field, if your
>>> query is "category:(test m*)" the parsed query will be "category:test
>>> OR
>>>
Re: Query parser behavior with AND and negative clause
Hi Erick,
The example record contains ...dateRange1 = [2016-11-22T18:00:00Z TO
2016-11-22T20:00:00Z], [2016-11-22T06:00:00Z TO 2016-11-22T14:00:00Z]dateRange2
= [2016-11-22T12:00:00Z TO 2016-11-22T14:00:00Z]"
The first query works ... which means that it is able to EXCLUDE this record
from the result (since the negative dateRange2 clause should return false).
Whereas the second query should also work but it does not and actually pulls
the record in the result.
WORKS:
+{!field f=dateRange1 op=Intersects v='[2016-11-22T12:01:00Z TO
2016-11-22T13:59:00Z]'} +(*:* -{!field f=dateRange2 op=Contains
v='[2016-11-22T12:01:00Z TO 2016-11-22T13:59:00Z]'})
DOES NOT WORK :
{!field f=dateRange1 op=Intersects v='[2016-11-22T12:01:00Z TO
2016-11-22T13:59:00Z]'} AND (*:* -{!field f=dateRange2 op=Contains
v='[2016-11-22T12:01:00Z TO 2016-11-22T13:59:00Z]'})
SRK
On Tuesday, November 22, 2016 9:41 PM, Erick Erickson
wrote:
_How_ does it "not work"? You haven't told us what you expect .vs.
what you get back.
Plus a sample doc that that violates your expectations (just the
dateRange field) would
also help.
Best,
Erick
On Tue, Nov 22, 2016 at 4:23 AM, Sandeep Khanzode
wrote:
> Hi,
> I have a simple query that should intersect with dateRange1 and NOT be
> contained within dateRange2. I have tried the following options:
>
> WORKS:
> +{!field f=dateRange1 op=Intersects v='[2016-11-22T12:01:00Z TO
> 2016-11-22T13:59:00Z]'} +(*:* -{!field f=dateRange2 op=Contains
> v='[2016-11-22T12:01:00Z TO 2016-11-22T13:59:00Z]'})
>
>
> DOES NOT WORK :
> {!field f=dateRange1 op=Intersects v='[2016-11-22T12:01:00Z TO
> 2016-11-22T13:59:00Z]'} AND (*:* -{!field f=dateRange2 op=Contains
> v='[2016-11-22T12:01:00Z TO 2016-11-22T13:59:00Z]'})
>
> Why?
>
> WILL NOT WORK (because of the negative clause at the top level?):
> {!field f=dateRange1 op=Intersects v='[2016-11-22T12:01:00Z TO
> 2016-11-22T13:59:00Z]'} AND -{!field f=dateRange2 op=Contains
> v='[2016-11-22T12:01:00Z TO 2016-11-22T13:59:00Z]'}
>
>
> SRK
Re: Wildcard searches with space in TextField/StrField
Hi All, Erick,
Please suggest. Would like to use the ComplexPhraseQueryParser for searching
text (with wildcard) that may contain special characters.
For example ...John* should match John V. DoeJohn* should match Johnson
SmithBruce-Willis* should match Bruce-WillisV.* should match John V. F. Doe
SRK
On Thursday, November 24, 2016 5:57 PM, Sandeep Khanzode
wrote:
Hi,
This is the typical TextField with ...
SRK
On Thursday, November 24, 2016 1:38 AM, Reth RM
wrote:
what is the fieldType of those records?
On Tue, Nov 22, 2016 at 4:18 AM, Sandeep Khanzode
wrote:
Hi Erick,
I gave this a try.
These are my results. There is a record with "John D. Smith", and another named
"John Doe".
1.] {!complexphrase inOrder=true}name:"John D.*" ... does not fetch any
results.
2.] {!complexphrase inOrder=true}name:"John D*" ... fetches both results.
Second observation: There is a record with "John D Smith"
1.] {!complexphrase inOrder=true}name:"John*" ... does not fetch any results.
2.] {!complexphrase inOrder=true}name:"John D*" ... fetches that record.
3.] {!complexphrase inOrder=true}name:"John D S*" ... fetches that record.
SRK
On Sunday, November 13, 2016 7:43 AM, Erick Erickson
wrote:
Right, for that kind of use case you want complexPhraseQueryParser,
see: https://cwiki.apache.org/ confluence/display/solr/Other+
Parsers#OtherParsers- ComplexPhraseQueryParser
Best,
Erick
On Sat, Nov 12, 2016 at 9:39 AM, Sandeep Khanzode
wrote:
> Thanks, Erick.
>
> I am actually not trying to use the String field (prefer a TextField here).
> But, in my comparisons with TextField, it seems that something like phrase
> matching with whitespace and wildcard (like, 'my do*' or say, 'my dog*', or
> say, 'my dog has*') can only be accomplished with a string type field,
> especially because, with a WhitespaceTokenizer in TextField, the space will
> be lost, and all tokens will be individually considered. Am I missing
> something?
>
> SRK
>
>
> On Friday, November 11, 2016 10:05 PM, Erick Erickson
> wrote:
>
>
> You have to query text and string fields differently, that's just the
> way it works. The problem is getting the query string through the
> parser as a _single_ token or as multiple tokens.
>
> Let's say you have a string field with the "a b" example. You have a
> single token
> a b that starts at offset 0.
>
> But with a text field, you have two tokens,
> a at position 0
> b at position 1
>
> But when the query parser sees "a b" (without quotes) it splits it
> into two tokens, and only the text field has both tokens so the string
> field won't match.
>
> OTOH, when the query parser sees "a\ b" it passes this through as a
> single token, which only matches the string field as there's no
> _single_ token "a b" in the text field.
>
> But a more interesting question is why you want to search this way.
> String fields are intended for keywords, machine-generated IDs and the
> like. They're pretty useless for searching anything except
> 1> exact tokens
> 2> prefixes
>
> While if you have "my dog has fleas" in a string field, you _can_
> search "*dog*" and get a hit but the performance is poor when you get
> a large corpus. Performance for "my*" will be pretty good though.
>
> In all this sounds like an XY problem, what's the use-case you're
> trying to solve?
>
> Best,
> Erick
>
>
>
> On Thu, Nov 10, 2016 at 10:11 PM, Sandeep Khanzode
> wrote:
>> Hi Erick, Reth,
>>
>> The 'a\ b*' as well as the q.op=AND approach worked (successfully) only
>> for StrField for me.
>>
>> Any attempt at creating a 'a\ b*' for a TextField does not match any
>> documents. The parsedQuery in debug mode does show 'field:a b*'. I am sure
>> there are documents that should match.
>> Another (maybe unrelated) observation is if I have 'field:a\ b', then the
>> parsedQuery is field:a field:b. Which does not match as expected (matches
>> individually).
>>
>> Can you please provide an example that I can use in Solr Query dashboard?
>> That will be helpful.
>>
>> I have also seen that wildcard queries work irrespective of field type
>> i.e. StrField as well as TextField. That makes sense because with a
>> WhitespaceTokenizer only creates word boundaries when we do not use a
>> EdgeNGramFilter. If I am not wrong, that is. SRK
>>
>> On Friday, November 11, 2016 5:00 AM, Erick Erickson
>> wrote:
>>
>>
>>
Re: Wildcard searches with space in TextField/StrField
Hi All,
Can someone please assist with this query?
My data consists of:
1.] John Doe
2.] John V. Doe
3.] Johnson Doe
4.] Johnson V. Doe
5.] John Smith
6.] Johnson V. Smith
7.] Matt Doe
8.] Matt V. Doe
9.] Matt Doe
10.] Matthew V. Doe
11.] Matthew Smith
12.] Matthew V. Smith
Querying ...
(a) Matt/Matt* should return records 7-12
(b) John/John* should return records 1-6
(c) Doe/Doe* should return records 1-4, 7-10
(d) Smith/Smith* should return records 5,6,11,12
(e) V/V./V.*/V* should return records 2,4,6,8,10,12
(f) V. Doe/V. Doe* should return records 2,4,8,10
(g) John V/John V./John V*/John V.* should return record 2
(h) V. Smith/V. Smith* should return records 6,12
Any guidance would be appreciated!
I have tried ComplexPhraseQueryParser, but with a single token like Doe*, there
is an error that indicates that the query is being identified as a prefix
query. I may be missing something in the syntax.
SRK
On Thursday, November 24, 2016 11:16 PM, Sandeep Khanzode
wrote:
Hi All, Erick,
Please suggest. Would like to use the ComplexPhraseQueryParser for searching
text (with wildcard) that may contain special characters.
For example ...John* should match John V. DoeJohn* should match Johnson
SmithBruce-Willis* should match Bruce-WillisV.* should match John V. F. Doe
SRK
On Thursday, November 24, 2016 5:57 PM, Sandeep Khanzode
wrote:
Hi,
This is the typical TextField with ...
SRK
On Thursday, November 24, 2016 1:38 AM, Reth RM
wrote:
what is the fieldType of those records?
On Tue, Nov 22, 2016 at 4:18 AM, Sandeep Khanzode
wrote:
Hi Erick,
I gave this a try.
These are my results. There is a record with "John D. Smith", and another named
"John Doe".
1.] {!complexphrase inOrder=true}name:"John D.*" ... does not fetch any
results.
2.] {!complexphrase inOrder=true}name:"John D*" ... fetches both results.
Second observation: There is a record with "John D Smith"
1.] {!complexphrase inOrder=true}name:"John*" ... does not fetch any results.
2.] {!complexphrase inOrder=true}name:"John D*" ... fetches that record.
3.] {!complexphrase inOrder=true}name:"John D S*" ... fetches that record.
SRK
On Sunday, November 13, 2016 7:43 AM, Erick Erickson
wrote:
Right, for that kind of use case you want complexPhraseQueryParser,
see: https://cwiki.apache.org/ confluence/display/solr/Other+
Parsers#OtherParsers- ComplexPhraseQueryParser
Best,
Erick
On Sat, Nov 12, 2016 at 9:39 AM, Sandeep Khanzode
wrote:
> Thanks, Erick.
>
> I am actually not trying to use the String field (prefer a TextField here).
> But, in my comparisons with TextField, it seems that something like phrase
> matching with whitespace and wildcard (like, 'my do*' or say, 'my dog*', or
> say, 'my dog has*') can only be accomplished with a string type field,
> especially because, with a WhitespaceTokenizer in TextField, the space will
> be lost, and all tokens will be individually considered. Am I missing
> something?
>
> SRK
>
>
> On Friday, November 11, 2016 10:05 PM, Erick Erickson
> wrote:
>
>
> You have to query text and string fields differently, that's just the
> way it works. The problem is getting the query string through the
> parser as a _single_ token or as multiple tokens.
>
> Let's say you have a string field with the "a b" example. You have a
> single token
> a b that starts at offset 0.
>
> But with a text field, you have two tokens,
> a at position 0
> b at position 1
>
> But when the query parser sees "a b" (without quotes) it splits it
> into two tokens, and only the text field has both tokens so the string
> field won't match.
>
> OTOH, when the query parser sees "a\ b" it passes this through as a
> single token, which only matches the string field as there's no
> _single_ token "a b" in the text field.
>
> But a more interesting question is why you want to search this way.
> String fields are intended for keywords, machine-generated IDs and the
> like. They're pretty useless for searching anything except
> 1> exact tokens
> 2> prefixes
>
> While if you have "my dog has fleas" in a string field, you _can_
> search "*dog*" and get a hit but the performance is poor when you get
> a large corpus. Performance for "my*" will be pretty good though.
>
> In all this sounds like an XY problem, what's the use-case you're
> trying to solve?
>
> Best,
> Erick
>
>
>
> On Thu, Nov 10, 2016 at 10:11 PM, Sandeep Khanzode
> wrote:
>> Hi Erick, Reth,
>>
>> The 'a\ b*' as well as the q.op=AND approach worked (successfully) only
>> for StrF
Re: Query parser behavior with AND and negative clause
WORKS:
+{!field f=dateRange1 op=Intersects v='[2016-11-22T12:01:00Z TO
2016-11-22T13:59:00Z]'} +(*:* -{!field f=dateRange2 op=Contains
v='[2016-11-22T12:01:00Z TO 2016-11-22T13:59:00Z]'})
+ConstantScore(IntersectsPrefixTreeFilter(fieldName=dateRange1,queryShape=[2016-11-22T12:01
TO 2016-11-22T13:59:00],detailLevel=9,prefixGridScanLevel=7))
+(MatchAllDocsQuery(*:*)
-ConstantScore(ContainsPrefixTreeFilter(fieldName=dateRange2,queryShape=[2016-11-22T12:01
TO 2016-11-22T13:59:00],detailLevel=9,multiOverlappingIndexedShapes=true)))
DOES NOT WORK :
{!field f=dateRange1 op=Intersects v='[2016-11-22T12:01:00Z TO
2016-11-22T13:59:00Z]'} AND (*:* -{!field f=dateRange2 op=Contains
v='[2016-11-22T12:01:00Z TO 2016-11-22T13:59:00Z]'})
ConstantScore(IntersectsPrefixTreeFilter(fieldName=dateRange1,queryShape=[2016-11-22T12:01
TO 2016-11-22T13:59:00],detailLevel=9,prefixGridScanLevel=7))
SRK
On Thursday, November 24, 2016 9:02 PM, Alessandro Benedetti
wrote:
Hey Sandeep,
can you debug the query ( debugQuery=on) and show how the query is parsed ?
Cheers
On Thu, Nov 24, 2016 at 12:38 PM, Sandeep Khanzode <
sandeep_khanz...@yahoo.com.invalid> wrote:
> Hi Erick,
> The example record contains ...dateRange1 = [2016-11-22T18:00:00Z TO
> 2016-11-22T20:00:00Z], [2016-11-22T06:00:00Z TO
> 2016-11-22T14:00:00Z]dateRange2
> = [2016-11-22T12:00:00Z TO 2016-11-22T14:00:00Z]"
> The first query works ... which means that it is able to EXCLUDE this
> record from the result (since the negative dateRange2 clause should return
> false). Whereas the second query should also work but it does not and
> actually pulls the record in the result.
> WORKS:
> +{!field f=dateRange1 op=Intersects v='[2016-11-22T12:01:00Z TO
> 2016-11-22T13:59:00Z]'} +(*:* -{!field f=dateRange2 op=Contains
> v='[2016-11-22T12:01:00Z TO 2016-11-22T13:59:00Z]'})
>
>
> DOES NOT WORK :
> {!field f=dateRange1 op=Intersects v='[2016-11-22T12:01:00Z TO
> 2016-11-22T13:59:00Z]'} AND (*:* -{!field f=dateRange2 op=Contains
> v='[2016-11-22T12:01:00Z TO 2016-11-22T13:59:00Z]'})
> SRK
>
> On Tuesday, November 22, 2016 9:41 PM, Erick Erickson <
> erickerick...@gmail.com> wrote:
>
>
> _How_ does it "not work"? You haven't told us what you expect .vs.
> what you get back.
>
> Plus a sample doc that that violates your expectations (just the
> dateRange field) would
> also help.
>
> Best,
> Erick
>
> On Tue, Nov 22, 2016 at 4:23 AM, Sandeep Khanzode
> wrote:
> > Hi,
> > I have a simple query that should intersect with dateRange1 and NOT be
> contained within dateRange2. I have tried the following options:
> >
> > WORKS:
> > +{!field f=dateRange1 op=Intersects v='[2016-11-22T12:01:00Z TO
> 2016-11-22T13:59:00Z]'} +(*:* -{!field f=dateRange2 op=Contains
> v='[2016-11-22T12:01:00Z TO 2016-11-22T13:59:00Z]'})
> >
> >
> > DOES NOT WORK :
> > {!field f=dateRange1 op=Intersects v='[2016-11-22T12:01:00Z TO
> 2016-11-22T13:59:00Z]'} AND (*:* -{!field f=dateRange2 op=Contains
> v='[2016-11-22T12:01:00Z TO 2016-11-22T13:59:00Z]'})
> >
> > Why?
> >
> > WILL NOT WORK (because of the negative clause at the top level?):
> > {!field f=dateRange1 op=Intersects v='[2016-11-22T12:01:00Z TO
> 2016-11-22T13:59:00Z]'} AND -{!field f=dateRange2 op=Contains
> v='[2016-11-22T12:01:00Z TO 2016-11-22T13:59:00Z]'}
> >
> >
> > SRK
>
>
>
>
--
--
Benedetti Alessandro
Visiting card - http://about.me/alessandro_benedetti
Blog - http://alexbenedetti.blogspot.co.uk
"Tyger, tyger burning bright
In the forests of the night,
What immortal hand or eye
Could frame thy fearful symmetry?"
William Blake - Songs of Experience -1794 England
Collection API CREATE creates name like '_shard1_replica1'
Hi, I uploaded (upconfig) config (schema and solrconfig XMLs) to Zookeeper and then linked (linkconfig) the confname to a collection name. When I attempt to create a collection using the API like this .../solr/admin/collections?action=CREATE&name=abc&numShards=1&collection.configName=abc ... it creates a collection core named abc_shard1_replica1 and not simply abc. What is missing? SRK
Re: SolrJ doesn't work with Json facet api
For me, these variants have worked ...
solrQuery.add("json.facet", "...");
solrQuery.setParam("json.facet", "...");
You get ...
QueryResponse.getResponse().get("facets");
SRK
On Thursday, January 5, 2017 1:19 PM, Jeffery Yuan
wrote:
Thanks for your response.
We definitely use solrQuery.set("json.facet", "the json query here");
Btw we are using Solr 5.2.1.
--
View this message in context:
http://lucene.472066.n3.nabble.com/SolrJ-doesn-t-work-with-Json-facet-api-tp4299867p4312459.html
Sent from the Solr - User mailing list archive at Nabble.com.
