You might want to look at the soft/hard commit options for insuring
data integrity .vs. latency.
Here's a blog on this topic at the Solr level, but all the Solr stuff
is realized at the Lucene level
eventually, so
http://searchhub.org/2013/08/23/understanding-transaction-logs-softcommit-and-co
On Fri, Jan 17, 2014 at 7:42 AM, Mindaugas Žakšauskas wrote:
> On Fri, Jan 17, 2014 at 12:13 PM, Michael McCandless
>> Backing up, what is your app doing, that it so strongly relies on
>> knowing whether commit() would do anything? Usually, commit is
>> something you call rarely, for "safety" pur
On Fri, Jan 17, 2014 at 12:13 PM, Michael McCandless
> Backing up, what is your app doing, that it so strongly relies on
> knowing whether commit() would do anything? Usually, commit is
> something you call rarely, for "safety" purposes to ensure if the
> world comes crashing down, you'll have a k
On Fri, Jan 17, 2014 at 4:59 AM, Mindaugas Žakšauskas wrote:
> Hi,
>
>>> 1 indexWriter.deleteDocuments(query); // same for terms arg
>>> 2 if (indexWriter.hasUncommittedChanges()) {
>>> 3 indexWriter.commit();
>>> 4 }
>>
>> hasUncommittedChanges will return true if you deleted (by Term or
>
Hi,
>> 1 indexWriter.deleteDocuments(query); // same for terms arg
>> 2 if (indexWriter.hasUncommittedChanges()) {
>> 3 indexWriter.commit();
>> 4 }
>
> hasUncommittedChanges will return true if you deleted (by Term or
> Query), even if that Term or Query matches no documents.
Mhm, this is
On Thu, Jan 16, 2014 at 6:30 AM, Mindaugas Žakšauskas wrote:
> Hi,
>
> I was wondering what would be the best approach to deal with the
> situation when some documents are deleted and it is unclear on whether
> deletions have resulted any pending commits.
>
> In a single thread scenario this seems
