Commit Graph

134 Commits

Author SHA1 Message Date
Alex Ksikes 35f55608cc MLT Field Query: remove it from master
The MLT field query is simply replaced by a MLT query set to specififc field.
To simplify code maintenance we should deprecate it in 1.4 and remove it in
2.0.

Closes #8238
2014-10-29 10:19:00 +01:00
Alex Ksikes 0be5c60bce MLT Query: use ParseField#withAllDeprecated for percent_terms_to_match
Also the parameter was deprecated but not removed so we keep it in the doc and
mark it as deprecated ...

Closes #8241
2014-10-27 17:35:06 +01:00
Alex Ksikes 991f3e2cd3 Docs: fix tags for dfs and new like parameter 2014-10-27 15:42:44 +01:00
Alex Ksikes 4da407a869 MLT Query: versatile 'like' parameter
The MLT query has a lot of parameters. For example, a set of documents is
specified with either `like_text`, `ids` or `docs`, with at least one
parameter required. This commit groups all the document specification
parameters under one called `like`. The syntax is described below and could
easily be extended to allow for new means of specifying document input. The
`like_text`, `ids` and `docs` parameters are deprecated.

As a single piece text:

{
  "query": {
    "more_like_this": {
      "like": "some text here"
    }
  }
}

As a single item:

{
  "query": {
    "more_like_this": {
      "like": {
        "_index": "imdb",
        "_type": "movies",
        "_id": "88247"
      }
    }
  }
}

Or as a mixture of all:

{
  "query": {
    "more_like_this": {
      "like": [
        "Some random text ...",
        {
          "_index": "imdb",
          "_type": "movies",
          "_id": "88247"
        },
        {
          "_index": "imdb",
          "_type": "movies",
          "doc": {
            "title": "Document with an artificial title!"
          }
        }
      ]
    }
  }
}

Closes #8039
2014-10-25 11:04:51 +02:00
Andrei Kolosok c31a783930 Docs: Update filtered-query.asciidoc
Fix mistyping

Closes #8167
2014-10-21 09:45:19 +02:00
Andrei Kolosok 92abfc8e24 Docs: Update minimum-should-match.asciidoc
Add %-sign to examle in the last section

Closes #8157
2014-10-21 09:43:55 +02:00
David Pilato 0ff61e1d6f Add time_zone setting for query_string
Query String query now supports a new `time_zone` option based on JODA time zones.
When using a range on date field, the time zone is applied.

```json
{
"query": {
  "query_string": {
    "text": "date:[2012 TO 2014]",
    "timezone": "Europe/Paris"
  }
 }
}
```

Closes #7880.
2014-10-20 19:09:45 +02:00
John Michael Luy 86f6e21cdf Docs: Update query-string-query.asciidoc
Update sample

Closes #8024
2014-10-16 20:21:12 +02:00
Patrick Peschlow 340e0efcaa Docs: cross_type query needs to be cross_fields
Closes #8021
2014-10-15 18:27:48 +02:00
Chris Earle 9b84ad3c7b Adding "min" score mode to parent-child queries
Support for "max", "sum", and "avg" already existed.
2014-10-15 09:23:36 -05:00
Hang Su dd62e50861 fix mismatched curly bracket 2014-10-14 13:24:44 +02:00
David Pilato 6ae6a078de Search: add `format` support for date range filter and queries
When the date format is defined in mapping, you can not use another format when querying using range date query or filter.

For example, this won't work:

```
DELETE /test

PUT /test/t/1
{
  "date": "2014-01-01"
}

GET /test/_search
{
  "query": {
    "filtered": {
      "filter": {
        "range": {
          "date": {
            "from": "01/01/2014"
          }
        }
      }
    }
  }
}
```

It causes:

```
Caused by: org.elasticsearch.ElasticsearchParseException: failed to parse date field [01/01/2014], tried both date format [dateOptionalTime], and timestamp number
```

It could be nice if we can support at query time another date format just like we support `analyzer` at search time on String fields.

Something like:

```
GET /test/_search
{
  "query": {
    "filtered": {
      "filter": {
        "range": {
          "date": {
            "from": "01/01/2014",
            "format": "dd/MM/yyyy"
          }
        }
      }
    }
  }
}
```

Same for queries:

```
GET /test/_search
{
  "query": {
    "range": {
      "date": {
        "from": "01/01/2014",
        "format": "dd/MM/yyyy"
      }
    }
  }
}
```

Closes #7189.
2014-10-06 15:59:18 +02:00
Alex Ksikes 349b7a3a8b Term Vectors/MLT Query: support for different analyzers than default at field
This adds a `per_field_analyzer` parameter to the Term Vectors API, which
allows to override the default analyzer at the field. If the field already
stores term vectors, then they will be re-generated. Since the MLT Query uses
the Term Vectors API under its hood, this commits also adds the same ability
to the MLT Query, thereby allowing users to fine grain how each field item
should be processed and analyzed.

Closes #7801
2014-10-03 16:40:17 +02:00
Clinton Gormley ea7ed51014 Docs: Typoes on the range filter page 2014-09-30 19:28:35 +02:00
Alex Ksikes b118558962 MLT Query: Support for artificial documents
Previously, the only way to specify a document not present in the index was to
use `like_text`. This would usually lead to complex queries made of multiple
MLT queries per document field. This commit adds the ability to the MLT query
to directly specify documents not present in the index (artificial documents).
The syntax is similar to the Percolator API or to the Multi Term Vector API.

Closes #7725
2014-09-29 15:49:13 +02:00
Alex Ksikes 5014158d6b MLT Query: use minimum should match more extensive syntax
The minimum number of optional should clauses of the generated query to match
can now be set using the more extensive minimum should match syntax. This
makes the `percent_terms_to_match` parameter deprecated, and replaced in favor
to a new `minimum_should_match` parameter.

Closes #7898
2014-09-29 11:14:56 +02:00
Thom Dixon 2d7264cd03 GeoJSON is lon,lat
Although emphasized in the text, the example was backwards.

Closes #7843
2014-09-28 11:05:42 +02:00
Clinton Gormley cb00d4a542 Docs: Removed all the added/deprecated tags from 1.x 2014-09-26 21:04:42 +02:00
Alex Ksikes 51bf3e6730 MLT Query: fix percent_terms_to_match
The parameter `percent_terms_to_match` (percentage of terms that must match in
the generated query) was wrongly set to the top level boolean query. This
would lead to zero or all results type of situations. This commit ensures that
the parameter is indeed applied to the query of generated terms.

Closes #7754
2014-09-25 09:56:53 +02:00
Clinton Gormley df8b949c45 Docs: Typos on range filter
Closes #7713
2014-09-24 20:19:05 +02:00
David Pilato f2be8d83dc Docs: fix typo 2014-09-23 23:41:07 +02:00
Ulrich Reffle 4ed52073fa Docs: A simple typo.
Closes #7535
2014-09-11 11:17:49 +02:00
Clinton Gormley e0684c4f6e Docs: Update regexp-syntax.asciidoc
Closes #7419
2014-09-07 11:42:33 +02:00
Clinton Gormley 0578a703df Docs: Update prefix-query.asciidoc
Typo (missing word)

Closes #7283
2014-09-07 11:32:05 +02:00
Clinton Gormley cf001d6837 Docs: Adds missing explanation to multi-match
Closes #7281
2014-09-07 11:30:52 +02:00
pachanta 8bae96485e Docs: Update span-not-query.asciidoc
The example given does not clearly explain what the query does.

Closes #7049
2014-09-07 11:28:19 +02:00
Britta Weber c5ff70bf43 function_score: add optional weight parameter per function
Weights can be defined per function like this:

```
"function_score": {
    "functions": [
        {
            "filter": {},
            "FUNCTION": {},
            "weight": number
        }
        ...
```
If `weight` is given without `FUNCTION` then `weight` behaves like `boost_factor`.
This commit deprecates `boost_factor`.

The following is valid:

```
POST testidx/_search
{
  "query": {
    "function_score": {
      "weight": 2
    }
  }
}
POST testidx/_search
{
  "query": {
    "function_score": {
      "functions": [
        {
          "weight": 2
        },
        ...
      ]
    }
  }
}
POST testidx/_search
{
  "query": {
    "function_score": {
      "functions": [
        {
          "FUNCTION": {},
          "weight": 2
        },
        ...
      ]
    }
  }
}
POST testidx/_search
{
  "query": {
    "function_score": {
      "functions": [
        {
          "filter": {},
          "weight": 2
        },
        ...
      ]
    }
  }
}
POST testidx/_search
{
  "query": {
    "function_score": {
      "functions": [
        {
          "filter": {},
          "FUNCTION": {},
          "weight": 2
        },
        ...
      ]
    }
  }
}
```

The following is not valid:

```
POST testidx/_search
{
  "query": {
    "function_score": {
      "weight": 2,
      "FUNCTION(including boost_factor)": 2
    }
  }
}

POST testidx/_search
{
  "query": {
    "function_score": {
      "functions": [
        {
          "weight": 2,
          "boost_factor": 2
        }
      ]
    }
  }
}
````

closes #6955
closes #7137
2014-09-01 11:04:40 +02:00
Ryan Ernst 65afa1d93b FunctionScore: Refactor RandomScoreFunction to be consistent, and return values in rang [0.0, 1.0]
RandomScoreFunction previously relied on the order the documents were
iterated in from Lucene. This caused changes in ordering, with the same
seed, if documents moved to different segments. With this change, a
murmur32 hash of the _uid for each document is used as the "random"
value. Also, the hash is adjusted so as to only return values between
0.0 and 1.0 to enable easier manipulation to fit into users' scoring
models.

closes #6907, #7446
2014-08-27 08:37:25 -07:00
Lee Hinman c5c11b1837 [DOCS] Document NOT as a simple_query_string flag
Fixes #7426
2014-08-25 10:27:24 +02:00
Alex Ksikes e78694ae82 More Like This Query: defaults to all possible fields for items
Items with no specified field now defaults to all the possible fields from the
document source. Previously, we had required 'fields' to be specified either
as a top level parameter or for each item. The default behavior is now similar
to the MLT API.

Closes #7382
2014-08-22 15:07:22 +02:00
Alex Ksikes f1a6b4e9fe More Like This Query: Switch to using the multi-termvectors API
The term vector API can now generate term vectors on the fly, if the terms are
not already stored in the index. This commit exploits this new functionality
for the MLT query. Now the terms are directly retrieved using multi-
termvectors API, instead of generating them from the texts retrieved using the
multi-get API.

Closes #7014
2014-08-21 12:18:21 +02:00
Adrien Grand ea96359d82 Facets: Removal from master.
Close #7337
2014-08-21 10:34:39 +02:00
Britta Weber 639692943f Docs: Document distance type and sort mode for many to many geo_points
closes #7280
2014-08-18 16:15:55 +02:00
Lee Hinman 99b0faed14 [DOCS] document simple_query_string's `lenient` option 2014-08-18 15:56:06 +02:00
Xiao Yu 4f417aa774 Docs: Update nested-filter.asciidoc
Fix whitespace to standardize on spaces for indents on both code examples for readability.

Closes #6568
2014-08-18 13:09:00 +02:00
Britta Weber aa1dbc0778 Docs: Fix ambigous explanation of the "fields" parameter in `query_string` query
Closes #7292
2014-08-18 13:06:48 +02:00
Gheorghita Catalin Bordianu ca77db1c83 Fixed a typo 2014-08-14 16:27:30 +02:00
Konrad Feldmeier 657b954528 Resolve wording inconsistency
AND and OR filter docs talk about different targets for the operators. I
believe that both should be described in terms of modifying other 'filters'.
I also added articles for easier (human) parsing. This fixes #4762

Closes #7165
2014-08-05 17:16:53 +02:00
David Pilato 873a45eaba Search: add time zone setting for relative date math in range filter/query
Filters and Queries now supports `time_zone` parameter which defines which time zone should be applied to the query or filter to convert it to UTC time based value.

When applied on `date` fields the `range` filter and queries accept also a `time_zone` parameter.

The `time_zone` parameter will be applied to your input lower and upper bounds and will move them to UTC time based date:

[source,js]
--------------------------------------------------
{
    "constant_score": {
        "filter": {
            "range" : {
                "born" : {
                    "gte": "2012-01-01",
                    "lte": "now",
                    "time_zone": "+1:00"
                }
            }
        }
    }
}

{
    "range" : {
        "born" : {
            "gte": "2012-01-01",
            "lte": "now",
            "time_zone": "+1:00"
        }
    }
}
--------------------------------------------------

In the above examples, `gte` will be actually moved to `2011-12-31T23:00:00` UTC date.

NOTE: if you give a date with a timezone explicitly defined and use the `time_zone` parameter, `time_zone` will be
ignored. For example, setting `from` to `2012-01-01T00:00:00+01:00` with `"time_zone":"+10:00"` will still use `+01:00` time zone.

Closes #3729.
2014-08-04 15:42:03 +02:00
Clinton Gormley c367ae09e3 Update nested-query.asciidoc
Changed score_mode `total` to `sum` to be consistent with parent-child etc
2014-07-26 22:32:28 +02:00
Britta Weber 10201d511c [doc] Correct decay function equations in function_score description
Impact of decay and scale was missing from the equations.

Closes #6983
2014-07-23 17:33:22 +02:00
Simon Willnauer 5bfea56457 [DOCS] move all coming tags to added in master 2014-07-23 16:37:19 +02:00
babeya 81a83aab22 Docs: Update query-string-syntax.asciidoc
Closes #6253
2014-07-23 16:32:32 +02:00
Konrad Feldmeier 48812ff1f2 Reflect that 'field_value_factor' is only in 1.2.x
While the blogpost http://www.elasticsearch.org/blog/2014-04-02-this-week-in-elasticsearch/ states, that feature #5519 was
added to 1.x, the release notes for, e.g. v1.1.2, however tell otherwise.
Only the release notes for 1.2.0 list #5519 as a new feature.

Since the 1.x docs deprecate/discourage from using `_boost`, and seemingly give a migration example at
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping-boost-field.html#function-score-instead-of-boost
users of 1.1.x should be warned.
2014-07-23 15:49:03 +02:00
Clinton Gormley 254aa71693 Docs: Added Tiki Wiki integration
Closes #6746
2014-07-23 11:00:46 +02:00
Clinton Gormley a862732434 Docs: Typo 2014-07-21 18:51:49 +02:00
Brian Murphy cbd2a97abd [DOCS] : Indexed scripts/templates
These are the docs for the indexed scripts/templates feature.
Also moved the namespace for the REST endpoints.

Closes #6851
2014-07-16 10:49:02 +01:00
Malte Schirnacher 647a2a64a1 Docs: Update query-string-syntax.asciidoc
Closes #6853
2014-07-14 16:35:17 +02:00
Matthew L Daniel 53f2301eea Docs: Add clarifying text about regexp and terms
For the casual reader, the reference to "term queries" may be glossed over, yielding an unexpected result when using `regexp` queries.
This attempts to make that distinction more prominent.

Closes #6698
2014-07-03 11:39:57 +02:00
jnguyenx 1883f74cc0 Docs: Fixed missing comma in multi match query example 2014-07-03 08:17:09 +02:00