Re: How to get case-sensitive Terms?

Alexandre Rafalovitch wrote > What about copyField with the target being index only (docValue only?) and > no lowercase on the target field type? > > Solr is not a database, you are optimising for search. So duplicate, > multi-process, denormalise, create custom field types, etc. > > Regards, >

Re: Meaning of "Index" flag under properties and schema

I wonder if looking more directly at the indexes would allow you to get closer to the problem source. Have you tried comparing/exploring the indexes with Luke? It is in the Lucene distribution (not Solr), and there is a small explanation here:

Re: Atomic Update (nested), Unified Highlighter and Lazy Field Loading => Invalid Index

I think the issue is this existing bug, but needs to refer to toSolrInputDocument instead of toSolrDoc: https://issues.apache.org/jira/browse/SOLR-13034 Highlighting isn't involved; you just need to somehow get a document cached with lazy fields. In a test I was able to do this simply by doing a

Re: Meaning of "Index" flag under properties and schema

I was getting “illegal argument exception length must be >= 1” when I used significantTerms streaming expression, from this collection and field. I asked about that as a separate question on this list. I will get the whole exception stack trace the next time I am at the customer site. Why any

RE: Is 8.8.x going be stabilized and finalized?

Hi Shawn, Nice to know that Solr will be considered top level project of Apache. I asked based on earlier 3 version patterns. Just hoping that 8.8 would be long term stable, kind of like 7.7.x line-up. Thanks for the clarification. Regards, Subhajit From: Shawn

Re: Is 8.8.x going be stabilized and finalized?

To add to what Shawn said, RC's are made available to anyone interested in testing them and that helps us find bugs before release. RC2 for 8.8.1 is available for testing now, see dev mailing list for location. Please download it and verify it is stable for your use cases and environment. Tim

Re: Change field to DocValues

That's right, I want to avoid a complete reindexing process. But should I create another field with the docValues property or change the current field directly? Can I use streaming expressions to update the whole index or should I select and update using batches? Thanks, Mahmoud On Wed, Feb

Re: Atomic Update (nested), Unified Highlighter and Lazy Field Loading => Invalid Index

Thanks for more details. I was able to reproduce this locally! I hacked a test to look similar to what you are doing. BTW it's okay to fill out a JIRA imperfectly; they can always be edited :-). Once I better understand the nature of the bug today, I'll file an issue and respond with it here.

Re:Change field to DocValues

Hi: I think you are just trying to avoid complete re-index right? why don't you take a look at this: https://lucene.apache.org/solr/guide/8_0/updating-parts-of-documents.html At 2021-02-17 21:14:11, "Mahmoud Almokadem" wrote: >Hello, > >I've an integer field on an index with

Re: [SOLVED] UPDATE collection's Rule-based Replica Placement

Thanks Ilan and Aroop for replying. So not exactly move but rather *update* the existing set of rules so future replica placement will enforced by them. I managed to do so using the MODIFYCOLLECTION action:

Change field to DocValues

Hello, I've an integer field on an index with billions of documents and need to do facets on this field, unfortunately the field doesn't have the docValues property, so the FieldCache will be fired and use much memory. What is the best way to change the field to be docValues supported? Regards,

RE: Atomic Update (nested), Unified Highlighter and Lazy Field Loading => Invalid Index

Hello David, Thank you for your reply. It was very hard but finally I discovered how to reproduce it. I thought of issuing an issue but wasn't sure about the components and priority. I used the "tech products" configset, with the following changes: 1. Added 2. Added Than I inserted one