Skip to content

Query DSL: Field Query #47

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
kimchy opened this issue Mar 1, 2010 · 1 comment
Closed

Query DSL: Field Query #47

kimchy opened this issue Mar 1, 2010 · 1 comment

Comments

@kimchy
Copy link
Member

kimchy commented Mar 1, 2010

A new query, field query, which is very similar to the queryString query, except it works on a single field. It has the same parameters as the queryString (except for the defaultField). The idea is to make querying against a single field using the query string sytax (fuzzy, boolean, phrase, and so on).

Sample 1:

{
    field : { age : 34 }
}

Sample 2:

{
    field : { "name.first" : "+shay -kimchy" }
}

Sample 3:

{
    field : { 
        "name.first" : { 
            query : "+shay -kimchy", 
            boost : 2.0, 
            enablePositionIncrements : false 
        } 
    }
}
@kimchy
Copy link
Member Author

kimchy commented Mar 1, 2010

Query DSL: Field Query, closed by 4dbc167.

dadoonet added a commit that referenced this issue Jun 5, 2015
Due to this [change](#8018), we need to fix our tests for elasticsearch 1.4.0 and above.

Closes #47.

(cherry picked from commit 3a90982)
dadoonet added a commit that referenced this issue Jun 5, 2015
The UnicastHostsProvider implementation creates DiscoveryNodes that are used as an initial seed for unicast based discovery. At the moment it uses Version.CURRENT for those DiscoveryNode object, which confuses the backwards compatibility layer to think this nodes are of the latest version. This causes new nodes to fail to join old nodes as the ping serialization goes wrong. Instead we should use version.minimumCompatibilityVersion().

Closes #47.

(cherry picked from commit 188179f)
dadoonet added a commit that referenced this issue Jun 5, 2015
Described in #10614, it's not possible with cloud discovery plugin to update dynamic settings anymore.

```sh
curl -XPUT localhost:9200/_cluster/settings -d '{
    "persistent" : {
        "discovery.zen.minimum_master_nodes" : 3
    },
    "transient" : {
        "discovery.zen.minimum_master_nodes" : 3
    }
}'
```

gives

```json
{"acknowledged":true,"persistent":{},"transient":{}}
```

Closes #47.

(cherry picked from commit 9df33a3)
(cherry picked from commit a40016e)
ywelsch pushed a commit to ywelsch/elasticsearch that referenced this issue May 24, 2018
Add details of the publication that is timing out, and more timings to the
start/end of stabilisation. Also the logging of the start of the stabilisation
phase wasn't actually at the start.
ClaudioMFreitas pushed a commit to ClaudioMFreitas/elasticsearch-1 that referenced this issue Nov 12, 2019
henningandersen pushed a commit to henningandersen/elasticsearch that referenced this issue Jun 4, 2020
With this commit we add a smoke test script that allows to run a
benchmark in test mode against (almost) all challenges in this track. A
few challenges have been excluded intentionally because they rely on
other challenges being run first. While it would be possible to make
this work with workarounds we should wait for a proper solution with
elastic/rally#697

Relates elastic#47
henningandersen pushed a commit to henningandersen/elasticsearch that referenced this issue Jun 4, 2020
With this commit we use the proper index template for the bulk-update
challenge. Previously neither the index template nor the custom index
settings have been applied, resulting in a default index being created
unintentionally. This issue has been discovered by the smoke test script
that we have added in elastic#47

Relates elastic#50
cbuescher pushed a commit to cbuescher/elasticsearch that referenced this issue Oct 2, 2023
There are some corner cases, like [1], when unmounting our (encrypted or not)
data volume succeeds but the subsequent mount remove task fails;
presumably this is a strange race condition due to the speed of
execution between the two tasks.

Make mount remove task more resilient but adding retries if it fails.

Closes elastic#47
Relates  elastic#48

[1] https://groups.google.com/a/elastic.co/d/msg/build-elasticsearch/nK8N3QQlpxI/1eE3WZBcAQAJ
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant