Sounds like you should have separate clusters. Maybe "production" vs.
"staged". Build up your new document base in "staged", test it all out and
then "flip a switch" and staged goes live and then the old production can be
recycled.
Or, maybe have a "pipeline" where new docs are indexed on put on a smaller
cluster (or even a single node), tested/verified, and only then passed along
to the "production" system.
Other than that, the most you can do with uncommited data is call real-time
get to retieve docs based solely on a list of IDs.
-- Jack Krupansky
-----Original Message-----
From: Furkan KAMACI
Sent: Friday, August 02, 2013 4:48 AM
To: solr-user@lucene.apache.org
Subject: How to run a verification process at pre-commit documents and then
commit them into live indexes if they are valid?
I use Solr 4.2.1 as SolrCloud. My live indexes will be search by huge
amounts of users and I don't want to have anything wrong. I have some
criteria for my indexes. i.e. there mustn't be spam documents at my index
(I have a spam detector tool), some documents should be at first result
page (or within first and second result page, doesn't important) when I
search for certain keywords (I don't want to organize them with query
elevation, it doesn't important to be at first row or tenth.
So I want to run a index verification tool for my indexes. How can I do
that with SolrCloud? Should I build a pseudo SolrCloud, make tests on them
and if everything OK then send to live SolrCloud? Or can I send documents
to SolrCloud, don't commit them into live indexes then run that
verification tool for not yet committed documents and then if everything is
OK commit them.
What do you prefer me for such cases who wants to run a verification
process at their indexes before commit them into live indexes?
