> On Apr 25, 2017, at 11:23 AM, Erick Erickson wrote:
>
> Maybe the other thing in play here is that use-cases that "just work"
> in the master/slave environment are less likely to employ consultants
> so we get something of a skewed sense of who uses what ;)
>
So, there’s a new poll you just
> On Apr 25, 2017, at 10:28 AM, AJ Lemke wrote:
>
> Thanks for the thought Alex!
> The fields that have this happen most often are numeric and boolean fields.
> These fields have real data (id numbers, true/false, etc.)
>
> AJ
>
We had an identical problem a few months ago, and there was no
>
> You have indicated that you have a way to avoid doing updates during the
> full import. Because of this, you do have another option that is likely
> much easier for you to implement: Set the "commitWithin" parameter on
> each update request. This works almost identically to autoSoftCommit,
> On Mar 3, 2017, at 11:30 AM, Erick Erickson wrote:
>
> One way to handle this (presuming SolrCloud) is collection aliasing.
> You create two collections, c1 and c2. You then have two aliases. when
> you start "index" is aliased to c1 and "search" is aliased to c2. Now
> do your full import to
>
> On Mar 3, 2017, at 11:22 AM, Alexandre Rafalovitch wrote:
>
> On 3 March 2017 at 12:17, Sales
> wrote:
>> When we enabled those, during the index, the data disappeared since it kept
>> soft committing during the import process,
>
> This part does not q
I am not sure how best to handle this. We use the data import handle to re-sync
all our data on a daily basis, takes 1-2 hours depending on system load. It is
set up to commit at the end, so, the old index remains until it’s done, and, we
lose no access while the import is happening.
But, we no
lly in
> your index.
>
> Best,
> Erick
>
> On Thu, Mar 2, 2017 at 3:18 PM, Sales
> wrote:
>> We are using Solr 4.10.4. I have a few Solr fields in schema.xml defined as
>> follows:
>>
>> > multiValued="true" stored="false" req
We are using Solr 4.10.4. I have a few Solr fields in schema.xml defined as
follows:
Both of them are loaded in via data-config.xml import handler, and they are
defined there as:
This has been working for years, but, lately, we have noticed strange
