parent
2b57dd7d3e
commit
e31049988b
|
@ -59,7 +59,7 @@
|
|||
|
||||
* http://searchbox-io.github.com/wp-elasticsearch/[Wp-Elasticsearch]:
|
||||
Elasticsearch WordPress Plugin
|
||||
|
||||
|
||||
* https://github.com/wallmanderco/elasticsearch-indexer[Elasticsearch Indexer]:
|
||||
Elasticsearch WordPress Plugin
|
||||
|
||||
|
@ -90,7 +90,7 @@
|
|||
A Java Object Search Engine Mapping (OSEM) for Elasticsearch
|
||||
|
||||
* https://github.com/twitter/storehaus[Twitter Storehaus]:
|
||||
Thin asynchronous scala client for storehaus.
|
||||
Thin asynchronous Scala client for Storehaus.
|
||||
|
||||
* https://doc.tiki.org/Elasticsearch[Tiki Wiki CMS Groupware]
|
||||
Tiki has native support for Elasticsearch. This provides faster & better search (facets, etc), along with some Natural Language Processing features (ex.: More like this)
|
||||
|
|
|
@ -50,7 +50,7 @@ failure:
|
|||
[source,js]
|
||||
--------------------------------------------------
|
||||
indexR.success = {IndexResponse response ->
|
||||
pritnln "Indexed $response.id into $response.index/$response.type"
|
||||
println "Indexed $response.id into $response.index/$response.type"
|
||||
}
|
||||
indexR.failure = {Throwable t ->
|
||||
println "Failed to index: $t.message"
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
[[query-dsl-filters]]
|
||||
== Query DSL - Filters
|
||||
|
||||
elasticsearch provides a full Java query dsl in a similar manner to the
|
||||
elasticsearch provides a full Java query DSL in a similar manner to the
|
||||
REST {ref}/query-dsl.html[Query DSL]. The factory for filter
|
||||
builders is `FilterBuilders`.
|
||||
|
||||
|
@ -182,7 +182,7 @@ FilterBuilder filter = geoDistanceRangeFilter("pin.location") <1>
|
|||
<5> include lower value means that `from` is `gt` when `false` or `gte` when `true`
|
||||
<6> include upper value means that `to` is `lt` when `false` or `lte` when `true`
|
||||
<7> optimize bounding box: `memory`, `indexed` or `none`
|
||||
<8> distance computation mode: `GeoDistance.SLOPPY_ARC` (default), `GeoDistance.ARC` (slighly more precise but
|
||||
<8> distance computation mode: `GeoDistance.SLOPPY_ARC` (default), `GeoDistance.ARC` (slightly more precise but
|
||||
significantly slower) or `GeoDistance.PLANE` (faster, but inaccurate on long distances and close to the poles)
|
||||
|
||||
Note that you can cache the result using
|
||||
|
|
|
@ -58,7 +58,7 @@ document to not be deleted.
|
|||
|
||||
Many times, the routing value is not known when deleting a document. For
|
||||
those cases, when specifying the `_routing` mapping as `required`, and
|
||||
no routing value is specified, the delete will be broadcasted
|
||||
no routing value is specified, the delete will be broadcast
|
||||
automatically to all shards.
|
||||
|
||||
[float]
|
||||
|
|
|
@ -11,7 +11,7 @@ exception of the <<search-explain>> endpoints.
|
|||
[[search-routing]]
|
||||
== Routing
|
||||
|
||||
When executing a search, it will be broadcasted to all the index/indices
|
||||
When executing a search, it will be broadcast to all the index/indices
|
||||
shards (round robin between replicas). Which shards will be searched on
|
||||
can be controlled by providing the `routing` parameter. For example,
|
||||
when indexing tweets, the routing value can be the user name:
|
||||
|
|
|
@ -449,7 +449,7 @@ In order to best validate for resiliency in Elasticsearch, we rewrote the Elasti
|
|||
|
||||
Each of our integration tests runs against a cluster with a random number of nodes, and indices have a random number of shards and replicas. Merge settings change for every run, indexing is done in serial or async fashion or even wrapped in a bulk operation and thread pool sizes vary to ensure that we don’t produce a deadlock no matter what happens. The list of places we use this randomization infrastructure is long, and growing every day, and has saved us headaches several times before we shipped a particular feature.
|
||||
|
||||
At Elasticsearch, we live the philosophy that we can miss a bug once, but never a second time. We make our tests more evil as you go, introducing randomness in all the areas where we discovered bugs. We figure if our tests don’t fail, weare not trying hard enough! If you are interested in how we have evolved our test infrastructure over time check out https://github.com/elasticsearch/elasticsearch/issues?q=label%3Atest[issues labeled with ``test'' on GitHub].
|
||||
At Elasticsearch, we live the philosophy that we can miss a bug once, but never a second time. We make our tests more evil as you go, introducing randomness in all the areas where we discovered bugs. We figure if our tests don’t fail, we are not trying hard enough! If you are interested in how we have evolved our test infrastructure over time check out https://github.com/elasticsearch/elasticsearch/issues?q=label%3Atest[issues labeled with ``test'' on GitHub].
|
||||
|
||||
[float]
|
||||
=== Lucene Loses Data On File Descriptors Failure (STATUS: DONE, v0.90.0)
|
||||
|
|
Loading…
Reference in New Issue