Skip to content
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

Query DSL: queryString - allow to run against multiple fields #48

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

Query DSL: queryString - allow to run against multiple fields #48

kimchy opened this issue Mar 1, 2010 · 1 comment

Comments

@kimchy
Copy link
Member

kimchy commented Mar 1, 2010

The current queryString requires to define the defaultField in order to run the query against a default field. Running the same query string against several "default" fields can be done by combining them either with bool or disMax queries, but its cumbersome.

queryString should support providing a "fields" field, where a list of fields the query will run against will be provided. An option to choose if the query will be combined using disMax or bool should be a simple flag. A tieBreaker field allowed when using disMax.

Sample 1:

{
    queryString : {
        fields : ["content", "name"],
        useDisMax : false,
        query: "test"
    }
}

Sample 2:

{
    queryString : {
        fields : ["content", "name"],
        useDisMax : true,
        query: "test"
    }
}

Boosting per field should be allowed, for example:

{
    queryString : {
        fields : ["content^1.4", "name"],
        query: "test"
    }
}
@kimchy
Copy link
Member Author

kimchy commented Mar 1, 2010

Query DSL: queryString - allow to run against multiple fields, closed by fdd221e.

dadoonet added a commit that referenced this issue Jun 5, 2015
Please change the Elasticsearch dependency to provided (and maybe testCompile) instead of compile and runtime.

Why? If you include the plugin in embedded Elasticsearch, and you exclude anything from the Elasticsearch dependency, it is undone by this dependency also including Elasticsearch. Therefore you have to tune both, when really this plugin only needs it as provided (since it runs with Elasticsearch or in Elasticsearch but never on its own).

Closes #48.
dadoonet pushed a commit that referenced this issue Jun 5, 2015
Please change the Elasticsearch dependency to provided (and maybe testCompile) instead of compile and runtime.

Why? If you include the plugin in embedded Elasticsearch, and you exclude anything from the Elasticsearch dependency, it is undone by this dependency also including Elasticsearch. Therefore you have to tune both, when really this plugin only needs it as provided (since it runs with Elasticsearch or in Elasticsearch but never on its own).

Related to #48.
dadoonet added a commit that referenced this issue Jun 5, 2015
rmuir pushed a commit to rmuir/elasticsearch that referenced this issue Nov 8, 2015
rmuir pushed a commit to rmuir/elasticsearch that referenced this issue Nov 8, 2015
ywelsch pushed a commit to ywelsch/elasticsearch that referenced this issue May 24, 2018
We face failing tests and other obstructions because of out-of-order processing
of tasks submitted to the `MasterService` provided by the test harness. Pending
a more nuanced notion of the batching of these tasks, this change batches all
submitted tasks together so we can make progress on other fronts.
dakrone added a commit that referenced this issue Oct 31, 2019
This test used an index without an alias to simulate a failure in the
`check-rollover-ready` step. However, with #48256 that step
automatically retries, meaning that the index may not always be in
the ERROR step.

This commit changes the test to use a shrink action with an invalid
number of shards so that it stays in the ERROR step.

Resolves #48767
ClaudioMFreitas pushed a commit to ClaudioMFreitas/elasticsearch-1 that referenced this issue Nov 12, 2019
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