On Nov 25, 2013, at 1:40 AM, adfel70 wrote:
> Just to clarify how these two phrases come together:
> 1. "you will know when an update is rejected - it just might not be easy to
> know which in the batch / stream"
>
> 2. "Documents that come in batches are added as they come / are processed -
>
Just to clarify how these two phrases come together:
1. "you will know when an update is rejected - it just might not be easy to
know which in the batch / stream"
2. "Documents that come in batches are added as they come / are processed -
not in some atomic unit."
If I send a batch of documents
If you want this promise and complete control, you pretty much need to do a doc
per request and many parallel requests for speed.
The bulk and streaming methods of adding documents do not have a good fine
grained error reporting strategy yet. It’s okay for certain use cases and and
especially b
Hi Mark, Thanks for the answer.
One more question though: You say that if I get a success from the update,
it’s in the system, commit or not. But when exactly do I get this feedback -
Is it one feedback per the whole request, or per one add inside the request?
I will give an example clarify my que
I suggest you to read here:
http://searchhub.org/2013/08/23/understanding-transaction-logs-softcommit-and-commit-in-sorlcloud/
Thanks;
Furkan KAMACI
2013/11/24 Mark Miller
> SolrCloud does not use commits for update acceptance promises.
>
> The idea is, if you get a success from the update, it
SolrCloud does not use commits for update acceptance promises.
The idea is, if you get a success from the update, it’s in the system, commit
or not.
Soft Commits are used for visibility only.
Standard Hard Commits are used essentially for internal purposes and should be
done via auto commit ge