Thanks Alex, I will check this out.
Is it possible to do something at query time , using a function query to
lowercase the field and then sort on it.?
Jay
> On Jun 24, 2016, at 12:03 AM, Alexandre Rafalovitch
> wrote:
>
> Keep voting for SOLR-8362?
>
> You could do your preprocessing in Upda
Keep voting for SOLR-8362?
You could do your preprocessing in UpdateRequestProcessor chain. There
is nothing specifically for Lower/Upper case, but there is a generic
scripting one:
http://www.solr-start.com/javadoc/solr-lucene/org/apache/solr/update/processor/StatelessScriptUpdateProcessorFactor
Any ideas on how to handle case insensitive search, string fields and
docvalues in 1 field?
On Thu, Jun 23, 2016 at 8:14 PM, Alexandre Rafalovitch
wrote:
> At least you don't need to store the sort field. Or even index, if it is
> docvalues (good for sort).
>
> Regards,
> Alex
> On 24 Jun 20
At least you don't need to store the sort field. Or even index, if it is
docvalues (good for sort).
Regards,
Alex
On 24 Jun 2016 9:01 AM, "Jay Potharaju" wrote:
> yes, that is what i thought. but was checking to see if there was something
> I was missing.
> Thanks
>
> On Thu, Jun 23, 2016 at
yes, that is what i thought. but was checking to see if there was something
I was missing.
Thanks
On Thu, Jun 23, 2016 at 12:55 PM, Ahmet Arslan
wrote:
> Hi Jay,
>
> I don't think it can be combined.
> Mainly because: searching requires a tokenized field.
> Sorting requires a single value (token
Hi Jay,
I don't think it can be combined.
Mainly because: searching requires a tokenized field.
Sorting requires a single value (token) to be meaningful.
Ahmet
On Thursday, June 23, 2016 7:43 PM, Jay Potharaju wrote:
Hi,
I would like to have 1 field that can used for both searching and case
i
