date:20210524

Solr 7(.5.5) -> Solr 8(.8.2) , different non-emptyness query behavior?

2021-05-24 Thread clemens...@mysign.ch

I have a unit test that tests the "non-emptyness query". As of updating from 
7.5.5 to 8.8.2 this very test fails and returns a document that has an empty 
string ( i.e. "" )
The "non-emptyness query" is:
fieldName:[* TO *]

Has the default "behavior" of the above query changed?

Does it possibly have anything to do with 
RemoveBlankFieldUpdateProcessorFactory?

Additional note: so far I haven't made any chages to the solrcofig.xml, so I am 
still using the same configuration as for 7.5.5

Regards
Clemens

Unique function not working for Solr (Ver: 6.0.1) nested facets

2021-05-24 Thread jay harkhani

Hello,

In our collection there are some documents which have same value for different 
fields while other have different values. i.e. For document1: status="xyz" and 
poi="draft", For document2: status="xyz" and poi="draft", For document3: 
status="abc" and poi="information". We have created facet query to search 
through all documents to get distinct count for documents where status="xyz" 
with poi="draft". Following query used to get count from solr:

json.facet={workspace:{type:terms,field:workspace,limit:100, 
facet:{x:"unique(doc_id)"},facet:{status:{type:terms,field:status,limit:-1, 
facet:{x:"unique(doc_id)"},facet:{poi:{type:terms,field:poi,limit:-1,facet:{x:"unique(doc_id)"}}}

Response from solr as below:

"facets":{
"count":4,
"workspace":{
  "buckets":[{
  "val":161650,
  "count":4,
  "status":{
"buckets":[{
"val":3,
"count":4,
"poi":{
  "buckets":[{
  "val":0,
  "count":4,
  "x":2}]}}]}}]}}}

Here we get unique document count for poi only. It not works for workspace and 
status field.

How can we apply unique function with multiple level of facet to get unique 
count in each level.

Regards,
Jay Harkhani.

Re: Unique function not working for Solr (Ver: 6.0.1) nested facets

2021-05-24 Thread Michael Gibney

I think your facet request syntax is wrong (you have duplicate "facet"
keys for all but the "leaf" (poi) facet, which is why you see the
"leaf"/poi facet working, but not the others). I wonder whether this
should throw a 400 error? In any case could you see whether the
following works as expected?:

workspace:{
  type:terms,
  field:workspace,
  limit:100,
  facet:{
x:"unique(doc_id)",
status:{
  type:terms,
  field:status,
  limit:-1,
  facet:{
x:"unique(doc_id)",
poi:{
  type:terms,
  field:poi,
  limit:-1,
  facet:{x:"unique(doc_id)"}
}
  }
}
  }
}

On Mon, May 24, 2021 at 11:12 AM jay harkhani  wrote:
>
> Hello,
>
> In our collection there are some documents which have same value for 
> different fields while other have different values. i.e. For document1: 
> status="xyz" and poi="draft", For document2: status="xyz" and poi="draft", 
> For document3: status="abc" and poi="information". We have created facet 
> query to search through all documents to get distinct count for documents 
> where status="xyz" with poi="draft". Following query used to get count from 
> solr:
>
> json.facet={workspace:{type:terms,field:workspace,limit:100, 
> facet:{x:"unique(doc_id)"},facet:{status:{type:terms,field:status,limit:-1, 
> facet:{x:"unique(doc_id)"},facet:{poi:{type:terms,field:poi,limit:-1,facet:{x:"unique(doc_id)"}}}
>
> Response from solr as below:
>
> "facets":{
> "count":4,
> "workspace":{
>   "buckets":[{
>   "val":161650,
>   "count":4,
>   "status":{
> "buckets":[{
> "val":3,
> "count":4,
> "poi":{
>   "buckets":[{
>   "val":0,
>   "count":4,
>   "x":2}]}}]}}]}}}
>
> Here we get unique document count for poi only. It not works for workspace 
> and status field.
>
> How can we apply unique function with multiple level of facet to get unique 
> count in each level.
>
> Regards,
> Jay Harkhani.

Re: Solr 7(.5.5) -> Solr 8(.8.2) , different non-emptyness query behavior?

2021-05-24 Thread Houston Putman

So the backend implementation of the fieldName:[* TO *] query has changed
as of 8.5 (SOLR-11746 ).
However I'm not sure that is resulting in the change here.

Are you using the RemoveBlankFieldUpdateProcessorFactory?

- Houston

On Mon, May 24, 2021 at 5:58 AM clemens...@mysign.ch 
wrote:

> I have a unit test that tests the "non-emptyness query". As of updating
> from 7.5.5 to 8.8.2 this very test fails and returns a document that has an
> empty string ( i.e. "" )
> The "non-emptyness query" is:
> fieldName:[* TO *]
>
> Has the default "behavior" of the above query changed?
>
> Does it possibly have anything to do with
> RemoveBlankFieldUpdateProcessorFactory?
>
> Additional note: so far I haven't made any chages to the solrcofig.xml, so
> I am still using the same configuration as for 7.5.5
>
> Regards
> Clemens
>

Re: Solr 7(.5.5) -> Solr 8(.8.2) , different non-emptyness query behavior?

2021-05-24 Thread clemens...@mysign.ch

Not explicitly, this being the requestHandler-section :




On 2021/05/24 16:15:22, Houston Putman  wrote:
> So the backend implementation of the fieldName:[* TO *] query has changed>
> as of 8.5 (SOLR-11746 ).>
> However I'm not sure that is resulting in the change here.>
>
> Are you using the RemoveBlankFieldUpdateProcessorFactory?>
>
> - Houston>
>
> On Mon, May 24, 2021 at 5:58 AM clemens...@mysign.ch >
> wrote:>
>
> > I have a unit test that tests the "non-emptyness query". As of updating>
> > from 7.5.5 to 8.8.2 this very test fails and returns a document that has an>
> > empty string ( i.e. "" )>
> > The "non-emptyness query" is:>
> > fieldName:[* TO *]>
> >>
> > Has the default "behavior" of the above query changed?>
> >>
> > Does it possibly have anything to do with>
> > RemoveBlankFieldUpdateProcessorFactory?>
> >>
> > Additional note: so far I haven't made any chages to the solrcofig.xml, so>
> > I am still using the same configuration as for 7.5.5>
> >>
> > Regards>
> > Clemens>
> >>
>

Re: Solr 7(.5.5) -> Solr 8(.8.2) , different non-emptyness query behavior?

2021-05-24 Thread Houston Putman

So I have tested out the logic of stringField:[* TO *], with empty strings
in 7.5 and 8.8. They perform identically, returning empty string values, if
they exist in the index
If I use the update processor chain with the "RemoveBlank" processor, the
documents with empty string values don't match. If I don't use that
processor chain, they do.
Would you check to see if there is a default updateRequestProcessorChain?
Those do not need to be specified in the requestHandler, so you won't see
them there..

Solr's default configSet comes with one, that includes the
RemoveBlankFieldUpdateProcessorFactory, by default unless you specify the
following java option: update.autoCreateFields=false
https://github.com/apache/solr/blob/main/solr/server/solr/configsets/_default/conf/solrconfig.xml#L1043

- Houston

On Mon, May 24, 2021 at 1:19 PM clemens...@mysign.ch 
wrote:

> Not explicitly, this being the requestHandler-section :
>  class="solr.UpdateRequestHandler">
>
>
>
> On 2021/05/24 16:15:22, Houston Putman  wrote:
> > So the backend implementation of the fieldName:[* TO *] query has
> changed>
> > as of 8.5 (SOLR-11746  >).>
> > However I'm not sure that is resulting in the change here.>
> >
> > Are you using the RemoveBlankFieldUpdateProcessorFactory?>
> >
> > - Houston>
> >
> > On Mon, May 24, 2021 at 5:58 AM clemens...@mysign.ch >
> > wrote:>
> >
> > > I have a unit test that tests the "non-emptyness query". As of
> updating>
> > > from 7.5.5 to 8.8.2 this very test fails and returns a document that
> has an>
> > > empty string ( i.e. "" )>
> > > The "non-emptyness query" is:>
> > > fieldName:[* TO *]>
> > >>
> > > Has the default "behavior" of the above query changed?>
> > >>
> > > Does it possibly have anything to do with>
> > > RemoveBlankFieldUpdateProcessorFactory?>
> > >>
> > > Additional note: so far I haven't made any chages to the
> solrcofig.xml, so>
> > > I am still using the same configuration as for 7.5.5>
> > >>
> > > Regards>
> > > Clemens>
> > >>
> >
>

Re: Solr 7(.5.5) -> Solr 8(.8.2) , different non-emptyness query behavior?

2021-05-24 Thread Chris Hostetter



: So I have tested out the logic of stringField:[* TO *], with empty strings
: in 7.5 and 8.8. They perform identically, returning empty string values, if
: they exist in the index

I remember seeing something like this pop up before ... not sure where ... 
but i bet Houston's comment above is baed on a quick test against a 
StrField, and I bet clemensdev is talking about a query against a TextField.

I think the issue is that when an Analyzer processes the input "" it 
produces no *terms* but the field still winds up with a norm value (based 
on term count of 0 fed to the similarity's norm() function) so the 
NormsFieldExistsQuery used in solr since SOLR-11746/8.5 matches a doc with 
a pre-analysis input of "", while the same doc won't match a PrefixQuery 
or RangeQuery that includes the literal term "" (because there are no 
terms to match the prefix/range)

All of which begs the question: Should lucene be generating a norm when 
there are 0 terms?



: documents with empty string values don't match. If I don't use that
: processor chain, they do.
: Would you check to see if there is a default updateRequestProcessorChain?
: Those do not need to be specified in the requestHandler, so you won't see
: them there..
: 
: Solr's default configSet comes with one, that includes the
: RemoveBlankFieldUpdateProcessorFactory, by default unless you specify the
: following java option: update.autoCreateFields=false
: 
https://github.com/apache/solr/blob/main/solr/server/solr/configsets/_default/conf/solrconfig.xml#L1043
: 
: - Houston
: 
: On Mon, May 24, 2021 at 1:19 PM clemens...@mysign.ch 
: wrote:
: 
: > Not explicitly, this being the requestHandler-section :
: >  class="solr.UpdateRequestHandler">
: >
: >
: >
: > On 2021/05/24 16:15:22, Houston Putman  wrote:
: > > So the backend implementation of the fieldName:[* TO *] query has
: > changed>
: > > as of 8.5 (SOLR-11746  >).>
: > > However I'm not sure that is resulting in the change here.>
: > >
: > > Are you using the RemoveBlankFieldUpdateProcessorFactory?>
: > >
: > > - Houston>
: > >
: > > On Mon, May 24, 2021 at 5:58 AM clemens...@mysign.ch >
: > > wrote:>
: > >
: > > > I have a unit test that tests the "non-emptyness query". As of
: > updating>
: > > > from 7.5.5 to 8.8.2 this very test fails and returns a document that
: > has an>
: > > > empty string ( i.e. "" )>
: > > > The "non-emptyness query" is:>
: > > > fieldName:[* TO *]>
: > > >>
: > > > Has the default "behavior" of the above query changed?>
: > > >>
: > > > Does it possibly have anything to do with>
: > > > RemoveBlankFieldUpdateProcessorFactory?>
: > > >>
: > > > Additional note: so far I haven't made any chages to the
: > solrcofig.xml, so>
: > > > I am still using the same configuration as for 7.5.5>
: > > >>
: > > > Regards>
: > > > Clemens>
: > > >>
: > >
: >
: 

-Hoss
http://www.lucidworks.com/

Re: Date string field not recognized...

2021-05-24 Thread Gaétan QUENTIN


Thanks for your answer.

It looks like quite complicated to add a custom UpdateRequestProcessor 
into sample_techproducts_configs type core.


Are there tools to help to do this ?

Lot of dates  are said invalid by solr but i don't see why. Most of docs 
are .ods / .odt :


msg=Invalid Date String:'2011-02-13T20:44:16'
msg=Invalid Date String:'2015-11-25T06:55:49.316556151'
msg=Invalid Date String:'2020-01-15T18:31:12.132601079'
msg=Invalid Date String:'2019-12-09T01:16:41.920883407'
msg=Invalid Date String:'2006-06-05T01:54:39'
msg=Invalid Date String:'2006-04-15T08:55:56'
msg=Invalid Date String:'2013-07-21T23:08:21'
msg=Invalid Date String:'2020-09-23T14:11:34.397265987'
msg=Invalid Date String:'2021-03-05T08:00:52.763074287'
msg=Invalid Date String:'2019-01-08T00:22:05.772138594'
msg=Invalid Date String:'2012-07-10T13:11:32'
msg=Invalid Date String:'2010-05-29T17:48:35'
msg=Invalid Date String:'2016-05-16T11:59:55.489935279'
msg=Invalid Date String:'2007-02-07T00:36:22'
msg=Invalid Date String:'2007-02-06T20:43:42'
msg=Invalid Date String:'2019-05-09T03:25:30.090833759'
msg=Invalid Date String:'2013-03-02T01:03:42'
msg=Invalid Date String:'2013-02-28T23:03:47'
msg=Invalid Date String:'2013-03-01T00:27:39'
msg=Invalid Date String:'2013-03-02T16:04:47'
msg=Invalid Date String:'2013-04-18T13:48:12'
msg=Invalid Date String:'2009-05-18T12:46:23'
msg=Invalid Date String:'2010-12-03T01:13:07'


Regards,

Gaétan
Le 15/05/2021 à 15:05, Alexandre Rafalovitch a écrit :

Not sure why the date is not recognized. But to parse alternative formats,
you can create a custom UpdateRequestProcessor with a number of formats to
accept.

That's part of how "schema less" mode works, you can explore that by
checking solrconfig.xml

Regards,
Alex

On Sat., May 15, 2021, 5:42 a.m. WORK Gaétan QUENTIN, <
work.gaetan.quen...@gmail.com> wrote:


Hi,


   I have a problem with dateformat not recognized in ods document:

Environment:

--


ubuntu 20.04, lxd container

openjdk version "14.0.2" 2020-07-14

solr 8.8.2


Problem:

--

Indexer fails with a LibreOffice document .ods file:

SimplePostTool: WARNING: Response: {
"responseHeader":{
"status":400,
"QTime":552},
"error":{
"metadata":[
"error-class","org.apache.solr.common.SolrException",
"root-error-class","org.apache.solr.common.SolrException"],
"msg":"ERROR: [doc=XXX.ods] Error adding field
'last_modified'='2019-01-08T00:22:05.772138594' msg=Invalid Date
String:'2019-01-08T00:22:05.772138594'",
"code":400}}

But i don't understand why: the date format looks ok for me.

The doc says that subseconds would be truncated if too long, and Z for
utc is not mandatory isn't it?


And question 2: how to tell solr to turn an invalid date format into a
valid one on the fly, or to recognize a new format?


Regards,

Gaétan

Re: Date string field not recognized...

2021-05-24 Thread Gaétan QUENTIN

I think it is because 'Z' is missing: i thought it was an option, but 
finaly is mandatory.  So how to tell solr to accept date without 'Z'?



Le 24/05/2021 à 22:59, Gaétan QUENTIN@Work a écrit :

Thanks for your answer.

It looks like quite complicated to add a custom UpdateRequestProcessor 
into sample_techproducts_configs type core.


Are there tools to help to do this ?

Lot of dates  are said invalid by solr but i don't see why. Most of 
docs are .ods / .odt :


msg=Invalid Date String:'2011-02-13T20:44:16'
msg=Invalid Date String:'2015-11-25T06:55:49.316556151'
msg=Invalid Date String:'2020-01-15T18:31:12.132601079'
msg=Invalid Date String:'2019-12-09T01:16:41.920883407'
msg=Invalid Date String:'2006-06-05T01:54:39'
msg=Invalid Date String:'2006-04-15T08:55:56'
msg=Invalid Date String:'2013-07-21T23:08:21'
msg=Invalid Date String:'2020-09-23T14:11:34.397265987'
msg=Invalid Date String:'2021-03-05T08:00:52.763074287'
msg=Invalid Date String:'2019-01-08T00:22:05.772138594'
msg=Invalid Date String:'2012-07-10T13:11:32'
msg=Invalid Date String:'2010-05-29T17:48:35'
msg=Invalid Date String:'2016-05-16T11:59:55.489935279'
msg=Invalid Date String:'2007-02-07T00:36:22'
msg=Invalid Date String:'2007-02-06T20:43:42'
msg=Invalid Date String:'2019-05-09T03:25:30.090833759'
msg=Invalid Date String:'2013-03-02T01:03:42'
msg=Invalid Date String:'2013-02-28T23:03:47'
msg=Invalid Date String:'2013-03-01T00:27:39'
msg=Invalid Date String:'2013-03-02T16:04:47'
msg=Invalid Date String:'2013-04-18T13:48:12'
msg=Invalid Date String:'2009-05-18T12:46:23'
msg=Invalid Date String:'2010-12-03T01:13:07'


Regards,

Gaétan
Le 15/05/2021 à 15:05, Alexandre Rafalovitch a écrit :
Not sure why the date is not recognized. But to parse alternative 
formats,
you can create a custom UpdateRequestProcessor with a number of 
formats to

accept.

That's part of how "schema less" mode works, you can explore that by
checking solrconfig.xml

Regards,
    Alex

On Sat., May 15, 2021, 5:42 a.m. WORK Gaétan QUENTIN, <
work.gaetan.quen...@gmail.com> wrote:


Hi,


   I have a problem with dateformat not recognized in ods document:

Environment:

--


ubuntu 20.04, lxd container

openjdk version "14.0.2" 2020-07-14

solr 8.8.2


Problem:

--

Indexer fails with a LibreOffice document .ods file:

SimplePostTool: WARNING: Response: {
"responseHeader":{
"status":400,
"QTime":552},
"error":{
"metadata":[
"error-class","org.apache.solr.common.SolrException",
"root-error-class","org.apache.solr.common.SolrException"],
"msg":"ERROR: [doc=XXX.ods] Error adding field
'last_modified'='2019-01-08T00:22:05.772138594' msg=Invalid Date
String:'2019-01-08T00:22:05.772138594'",
"code":400}}

But i don't understand why: the date format looks ok for me.

The doc says that subseconds would be truncated if too long, and Z for
utc is not mandatory isn't it?


And question 2: how to tell solr to turn an invalid date format into a
valid one on the fly, or to recognize a new format?


Regards,

Gaétan

Re: Date string field not recognized...

2021-05-24 Thread Walter Underwood

You could write an update request processor script to add a ‘Z’ to the end of 
that field.

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)

> On May 24, 2021, at 2:15 PM, Gaétan QUENTIN@Work 
>  wrote:
> 
> I think it is because 'Z' is missing: i thought it was an option, but finaly 
> is mandatory.  So how to tell solr to accept date without 'Z'?
> 
> 
> Le 24/05/2021 à 22:59, Gaétan QUENTIN@Work a écrit :
>> Thanks for your answer.
>> 
>> It looks like quite complicated to add a custom UpdateRequestProcessor into 
>> sample_techproducts_configs type core.
>> 
>> Are there tools to help to do this ?
>> 
>> Lot of dates  are said invalid by solr but i don't see why. Most of docs are 
>> .ods / .odt :
>> 
>> msg=Invalid Date String:'2011-02-13T20:44:16'
>> msg=Invalid Date String:'2015-11-25T06:55:49.316556151'
>> msg=Invalid Date String:'2020-01-15T18:31:12.132601079'
>> msg=Invalid Date String:'2019-12-09T01:16:41.920883407'
>> msg=Invalid Date String:'2006-06-05T01:54:39'
>> msg=Invalid Date String:'2006-04-15T08:55:56'
>> msg=Invalid Date String:'2013-07-21T23:08:21'
>> msg=Invalid Date String:'2020-09-23T14:11:34.397265987'
>> msg=Invalid Date String:'2021-03-05T08:00:52.763074287'
>> msg=Invalid Date String:'2019-01-08T00:22:05.772138594'
>> msg=Invalid Date String:'2012-07-10T13:11:32'
>> msg=Invalid Date String:'2010-05-29T17:48:35'
>> msg=Invalid Date String:'2016-05-16T11:59:55.489935279'
>> msg=Invalid Date String:'2007-02-07T00:36:22'
>> msg=Invalid Date String:'2007-02-06T20:43:42'
>> msg=Invalid Date String:'2019-05-09T03:25:30.090833759'
>> msg=Invalid Date String:'2013-03-02T01:03:42'
>> msg=Invalid Date String:'2013-02-28T23:03:47'
>> msg=Invalid Date String:'2013-03-01T00:27:39'
>> msg=Invalid Date String:'2013-03-02T16:04:47'
>> msg=Invalid Date String:'2013-04-18T13:48:12'
>> msg=Invalid Date String:'2009-05-18T12:46:23'
>> msg=Invalid Date String:'2010-12-03T01:13:07'
>> 
>> 
>> Regards,
>> 
>> Gaétan
>> Le 15/05/2021 à 15:05, Alexandre Rafalovitch a écrit :
>>> Not sure why the date is not recognized. But to parse alternative formats,
>>> you can create a custom UpdateRequestProcessor with a number of formats to
>>> accept.
>>> 
>>> That's part of how "schema less" mode works, you can explore that by
>>> checking solrconfig.xml
>>> 
>>> Regards,
>>> Alex
>>> 
>>> On Sat., May 15, 2021, 5:42 a.m. WORK Gaétan QUENTIN, <
>>> work.gaetan.quen...@gmail.com> wrote:
>>> 
 Hi,
 
 
I have a problem with dateformat not recognized in ods document:
 
 Environment:
 
 --
 
 
 ubuntu 20.04, lxd container
 
 openjdk version "14.0.2" 2020-07-14
 
 solr 8.8.2
 
 
 Problem:
 
 --
 
 Indexer fails with a LibreOffice document .ods file:
 
 SimplePostTool: WARNING: Response: {
 "responseHeader":{
 "status":400,
 "QTime":552},
 "error":{
 "metadata":[
 "error-class","org.apache.solr.common.SolrException",
 "root-error-class","org.apache.solr.common.SolrException"],
 "msg":"ERROR: [doc=XXX.ods] Error adding field
 'last_modified'='2019-01-08T00:22:05.772138594' msg=Invalid Date
 String:'2019-01-08T00:22:05.772138594'",
 "code":400}}
 
 But i don't understand why: the date format looks ok for me.
 
 The doc says that subseconds would be truncated if too long, and Z for
 utc is not mandatory isn't it?
 
 
 And question 2: how to tell solr to turn an invalid date format into a
 valid one on the fly, or to recognize a new format?
 
 
 Regards,
 
 Gaétan

Re: Solr 7(.5.5) -> Solr 8(.8.2) , different non-emptyness query behavior?

2021-05-24 Thread clemens...@mysign.ch

> if there is a default updateRequestProcessorChain
I'd say no. The update-handler entry looks alike:

and there ist no updateRequestProcessorChain

> clemensdev is talking about a query against a TextField
my test indeed makes use of a TextField



On 2021/05/24 19:40:26, Chris Hostetter  wrote: 
> 
> : So I have tested out the logic of stringField:[* TO *], with empty strings> 
> : in 7.5 and 8.8. They perform identically, returning empty string values, 
> if> 
> : they exist in the index> 
> 
> I remember seeing something like this pop up before ... not sure where ... > 
> but i bet Houston's comment above is baed on a quick test against a > 
> StrField, and I bet clemensdev is talking about a query against a TextField.> 
> 
> I think the issue is that when an Analyzer processes the input "" it > 
> produces no *terms* but the field still winds up with a norm value (based > 
> on term count of 0 fed to the similarity's norm() function) so the > 
> NormsFieldExistsQuery used in solr since SOLR-11746/8.5 matches a doc with > 
> a pre-analysis input of "", while the same doc won't match a PrefixQuery > 
> or RangeQuery that includes the literal term "" (because there are no > 
> terms to match the prefix/range)> 
> 
> All of which begs the question: Should lucene be generating a norm when > 
> there are 0 terms?> 
> 
> 
> 
> : documents with empty string values don't match. If I don't use that> 
> : processor chain, they do.> 
> : Would you check to see if there is a default updateRequestProcessorChain?> 
> : Those do not need to be specified in the requestHandler, so you won't see> 
> : them there..> 
> : > 
> : Solr's default configSet comes with one, that includes the> 
> : RemoveBlankFieldUpdateProcessorFactory, by default unless you specify the> 
> : following java option: update.autoCreateFields=false> 
> : 
> https://github.com/apache/solr/blob/main/solr/server/solr/configsets/_default/conf/solrconfig.xml#L1043>
>  
> : > 
> : - Houston> 
> : > 
> : On Mon, May 24, 2021 at 1:19 PM clemens...@mysign.ch > 
> : wrote:> 
> : > 
> : > Not explicitly, this being the requestHandler-section :> 
> : >  
> : > class="solr.UpdateRequestHandler">> 
> : >> 
> : >> 
> : >> 
> : > On 2021/05/24 16:15:22, Houston Putman  wrote:> 
> : > > So the backend implementation of the fieldName:[* TO *] query has> 
> : > changed>> 
> : > > as of 8.5 (SOLR-11746 
>  
> : > >).>> 
> : > > However I'm not sure that is resulting in the change here.>> 
> : > >> 
> : > > Are you using the RemoveBlankFieldUpdateProcessorFactory?>> 
> : > >> 
> : > > - Houston>> 
> : > >> 
> : > > On Mon, May 24, 2021 at 5:58 AM clemens...@mysign.ch 
> >> 
> : > > wrote:>> 
> : > >> 
> : > > > I have a unit test that tests the "non-emptyness query". As of> 
> : > updating>> 
> : > > > from 7.5.5 to 8.8.2 this very test fails and returns a document that> 
> : > has an>> 
> : > > > empty string ( i.e. "" )>> 
> : > > > The "non-emptyness query" is:>> 
> : > > > fieldName:[* TO *]>> 
> : > > >>> 
> : > > > Has the default "behavior" of the above query changed?>> 
> : > > >>> 
> : > > > Does it possibly have anything to do with>> 
> : > > > RemoveBlankFieldUpdateProcessorFactory?>> 
> : > > >>> 
> : > > > Additional note: so far I haven't made any chages to the> 
> : > solrcofig.xml, so>> 
> : > > > I am still using the same configuration as for 7.5.5>> 
> : > > >>> 
> : > > > Regards>> 
> : > > > Clemens>> 
> : > > >>> 
> : > >> 
> : >> 
> : > 
> 
> -Hoss> 
> http://www.lucidworks.com/> 
>

Solr 7(.5.5) -> Solr 8(.8.2) , different non-emptyness query behavior?

Unique function not working for Solr (Ver: 6.0.1) nested facets

Re: Unique function not working for Solr (Ver: 6.0.1) nested facets

Re: Solr 7(.5.5) -> Solr 8(.8.2) , different non-emptyness query behavior?

Re: Solr 7(.5.5) -> Solr 8(.8.2) , different non-emptyness query behavior?

Re: Solr 7(.5.5) -> Solr 8(.8.2) , different non-emptyness query behavior?

Re: Solr 7(.5.5) -> Solr 8(.8.2) , different non-emptyness query behavior?

Re: Date string field not recognized...

Re: Date string field not recognized...

Re: Date string field not recognized...

Re: Solr 7(.5.5) -> Solr 8(.8.2) , different non-emptyness query behavior?

11 matches

Site Navigation

Mail list logo

Footer information