when starting the request/response cycle, we should use the lowest version out of the current node version, and the target node version to serialize the request, and put it in the header. this will allow to support both backward and forward comp.
in addition, have Version as an injected value to different services, to make different versions more easily testable, compared to using Version#CURRENT
The percolate an existing document feature executes an internal get operation to get the source of the document to percolate.
All options for percolating an existing document:
* `id` - The id of the document to percolate.
* `type` - The type of the document to percolate.
* `index` - The index to fetch the document to percolate from.
* `routing` - The routing value to use to retrieve the document to percolate.
* `preference` - Which shard to prefer (defaults to `_local`).
* `version` - Enables a version check. If the fetched document's version isn't equal to the specified version then the request fails with a version conflict and the percolation request is aborted.
All the option can be specified inside the `get` body part or via query string arguments.
Internally the percolate api will issue a get request for fetching the`_source` of the document to percolate.
For this feature to work the `_source` for documents to percolate need to be stored.
Closes#3380
Default value is "total", possible values are: "max", "min", "avg",
"multiply" and "total".
- "total": the final score of a document is the sum of the original
query score with the rescore query score.
- "max": only the highest score count.
- "min": only the lowest score is kept (if the document doesn't match
the rescore query, the original query score is used).
- "avg": average of both scores
- "multiply": product of both scores
Closes#3258
Lucene might internally tie-break on low level doc-Ids which
can change depending on merges etc. and test timings. No test should
rely on the actual order if scores are identical.
Tests are more reproducible if documents are indexed in random order
with random flushes/refreshes etc. in order to catch corner cases
where doc Ids are used for tie-breaking and tests rely on a certain
order.
IndexGatewayTests rely on that all nodes have the same type of
storage to pass consistently. Random configs should be the same for all
nodes in the cluster.
If the score is equal in Lucene the order of the result depends on the
actual global doc ID such that due to background merges or concurrency
these test can return different result set orders.
Allow to update / merge in the dynamic flag on object or the root object mapper, meaning that it can be changed dynamically using the update mapping API.
closes#3384
For better integration with the Lucene Test Framework and the
availabilty of RandomizedRunner / Randommized Testing this commit
moves over from TestNG to JUnit.
This commit also moves relevant places over to RandomzedRunner for
reproduceability and removes copied classes from the Lucene Test
Framework.
if the index already exists, trace log it, since it might happen as a result of multiple index requests at the same time creating the index, all other ones, should be debug and not warn in the same spirit of other APIs
try and bulk as much as possible refresh and update mapping events, so they will all be processed at a single go, resulting in less cluster change events, and also reduce the load of multiple changes to the same index
also, change the prio for those to HIGH, since we want URGENT ones (like create index, delete index) to execute
Shay Banon
Nik Everett
Martijn van Groningen
Cédric HOURCADE
Simon Willnauer
Luca Cavanna
Lukas Vlcek
Boaz Leskes