Re: filtered has_child query?
Actually, I do want only parent documents returned, but I want the filter to be applied to both parent and child documents. Is there a way to specify that the filter is to be applied before the query, so that this would be possible? If not, how would I rewrite the query to do this? -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/05a86e8c-9ef2-4028-b937-e6370202e677%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: filtered has_child query?
On Wednesday, March 11, 2015 at 6:23:40 PM UTC-4, Perryn Fowler wrote:
>
> 'apply the filter before the query' doesn't make any sense to me - what
> would it filter? I suspect I'm not really understanding you, can you tell
> me more? Why do you want to be able to do this? How would it help?
>
The scenario is actually a very common one. We have a common field to all
document types (regardless of parent or child) whose purpose is to control
access. In this simple example, the access field represents this common
field. Ideally, it would be much simpler to be able to specify a *filter
then query* strategy in the filtered query which would apply the term
filter to all documents before the query is executed regardless of whether
or not the query included a has_parent query.
> anyway, from what I thing I do understand there are several ways to get
> the results you want. Which one you choose probably depends on how you want
> the results scored, and possibly performance considerations.
>
> here is one way to try. (If you want to filter both then you need to ...
> apply the filter to both :))
> something like:
>
> {
>"query": {
> "filtered": {
> "query": {
> "has_child": {
>"type": "Bar",
>"query": {
> "filtered": {
> "query": {
>"term": {
>"bar": "xyz"
> }
> },
> "filter": {
>"term": {
>"access": "yes"
>}
> }
> }
>}
> }
> },
> "filter": {
> "term": {
>"access": "yes"
> }
> }
> }
>}
> }
>
>
Thank you for your work-around solution. Unfortunately, it's not ideal
though, since in practice our filters can be very large, so it really
bloats the request to have to repeat the filter clause.
Thank you for your time though.
--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elasticsearch+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/7af03ba4-9654-49f3-98f0-b40ca297a56f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
filtered has_child query?
Is a filtered has_child query possible where the filter is applied to the
child document before the query of the has_child?
e.g. Given the example below...
curl -X PUT "http://localhost:9200/foobar"; -d
"{\"mappings\":{\"Foo\":{},\"Bar\":{\"_parent\":{\"type\":\"Foo\""
curl -X PUT "http://localhost:9200/foobar/Foo/1";
-d "{\"foo\":\"abc\",\"access\":\"yes\"}"
curl -X PUT "http://localhost:9200/foobar/Bar/2?parent=1";
-d "{\"bar\":\"xyz\",\"access\":\"no\"}"
The following filtered query should not return a result, if the filter was
being applied to the child document first.
{
"query": {
"filtered": {
"query": {
"has_child": {
"type": "Bar",
"query": {
"term": {
"bar": "xyz"
}
}
}
},
"filter": {
"term": {
"access": "yes"
}
}
}
}
}
Please advise.
--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elasticsearch+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/575c3aa3-169d-4f00-b353-9e54291da432%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
how to disable default-mapping.json for a new index?
I've got a couple dozen or so indexes for which I've defined config/default-mapping.json that includes dynamic_templates and properties which works fine; however, I now have a new index for which I do not want the default-mapping.json to apply. i.e. I just want to use the default out-of-the-box Elasticsearch dynamic mappings. What's the easiest way to do this without having to define every type in this new index? -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/d2aa8f4b-624f-4d76-8cc4-1b522e719777%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: include_in_all: false not working for nested multi-field mappings in default-mapping.json
>
> must be _default_, not _default as shown in your default-mapping.json
>
Ahhh...good catch. That was a typo. However, after fixing that typo, the
problem remains.
The aggs search result is the following:
{
took: 36
timed_out: false
_shards: {
total: 1
successful: 1
failed: 0
}
hits: {
total: 1
max_score: 0
hits: [ ]
}
aggregations: {
foo: {
buckets: [
{
key: elasticsearch
doc_count: 1
}
{
key: rule
doc_count: 1
}
]
}
}
}
My revised default-mapping.json is the following (I also changed an
analyzer):
{
"_default_": {
"properties": {
"foo": {
"type": "nested",
"include_in_all": false,
"properties": {
"bar": {
"type": "string",
"index": "not_analyzed",
"include_in_all": false,
"fields": {
"lower": {
"analyzer": "standard",
"type": "string"
}
}
}
}
}
}
}
}
The resulting metadata is the following:
{
state: open
settings: {
index: {
uuid: S2hmo2d3SGWFP51PXs6XbA
number_of_replicas: 0
number_of_shards: 1
version: {
created: 1000199
}
}
}
mappings: {
foobar: {
properties: {
foo: {
include_in_all: false
properties: {
bar: {
include_in_all: false
index: not_analyzed
type: string
fields: {
lower: {
analyzer: standard
type: string
}
}
}
}
type: nested
}
}
}
}
aliases: [ ]
}
So, is this a bug?
--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elasticsearch+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/e0dac3e7-d825-41d8-bb35-ab33ef8c7290%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
include_in_all: false not working for nested multi-field mappings in default-mapping.json
I'm running Elasticsearch 1.0.1 using the following
$ES_HOME/config/default-mapping.json:
{
"_default": {
"properties": {
"foo": {
"type": "nested",
"include_in_all": false,
"properties": {
"bar": {
"type": "string",
"index": "not_analyzed",
"include_in_all": false,
"fields": {
"lower": {
"analyzer": "lowercase",
"type": "string"
}
}
}
}
}
}
}
}
When i post the following, the include_in_all does not seem to be
recognized at any level:
{
"foo": {
"bar": "Elasticsearch rules!"
}
}
The resulting index metadata is the following:
{
state: open
settings: {
index: {
uuid: TJf_oVKLSzuGD1q8xWq9nw
number_of_replicas: 0
number_of_shards: 1
version: {
created: 1000199
}
}
}
mappings: {
foobar: {
properties: {
foo: {
properties: {
bar: {
type: string
}
}
}
}
}
}
aliases: [ ]
}
I verified that _all does include the "elasticsearch rules" via the
following aggregation search:
{
"aggs": {
"foobar": {
"terms": {
"field": "_all"
}
}
},
"size": 0
}
The aggregation results are the following:
{
took: 25
timed_out: false
_shards: {
total: 1
successful: 1
failed: 0
}
hits: {
total: 1
max_score: 0
hits: [ ]
}
aggregations: {
foo: {
buckets: [
{
key: elasticsearch
doc_count: 1
}
{
key: rules
doc_count: 1
}
]
}
}
}
Any idea what I'm doing wrong, or is this a bug?
--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elasticsearch+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/54564669-d69c-48a9-85b5-a0a9c8162ff7%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: terms facet/agg not working for nested types in 1.x
That worked!
After further review, I did in fact have that in my 0.90.7 config, but it
got lost in translation to my 1.0.1 config.
MANY THANKS!!
On Thursday, February 27, 2014 6:03:59 PM UTC-5, Binh Ly wrote:
>
> Try:
>
> {
>"_default_": {
> "properties": {
> "foo": {
> "type": "nested",
>
> *"include_in_parent": true,*
> "properties": {
>"bar": {
> "index": "analyzed",
> "type": "string"
>}
> }
> }
> }
>}
> }
>
> It's interesting that it worked in the previous version (I didn't expect
> it to). But the above should work in 1.x.
>
--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elasticsearch+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/f4c796a7-83db-4c3e-91c7-cc1286d37150%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
terms facet/agg not working for nested types in 1.x
I'm running Elasticsearch 1.0.1 with 1 node, 1 shard, 0 replicas for this
test.
My $ES_HOME/config/default-mapping.json is the following:
{
"_default_": {
"properties": {
"foo": {
"type": "nested",
"properties": {
"bar": {
"index": "analyzed",
"type": "string"
}
}
}
}
}
}
I add the following doc to test/foobar:
{
"foo": {
"bar": "Foo Bar"
}
}
When I POST the following facet (and similar agg):
{
"facets": {
"foobar": {
"terms": {
"field": "foo.bar"
}
}
},
"size": 0
}
I get the following results:
{
took: 52,
timed_out: false,
_shards: {
total: 1,
successful: 1,
failed: 0
},
hits: {
total: 1,
max_score: 0,
hits: []
},
facets: {
foo: {
_type: "terms",
missing: 1,
total: 0,
other: 0
terms: []
}
}
}
However, the similar setup/facet query worked in 0.90.7.
Please advise if this no longer works in 1.0.1 or if I'm doing something
wrong.
--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elasticsearch+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/3f3dfe39-99d6-419c-a4d0-c6e0d95a6e93%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
copy_to objects?
Does copy_to work with objects? -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/ec31c050-3414-4747-ba77-7e25c7418b88%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
dynamic template multi-field w/ _all combo analyzer issue?
I'm seeing duplicate concatenated values when using the combo analyzer for
_all using a multi-field defined in a dynamic template.
e.g. Instead of seeing "Foo Bar" when listing the _all terms aggregation,
I'm seeing "Foo Bar Foo Bar" for the token because my mulit-field defines 2
sub-fields. If the multi-field is defined with 4 sub-fields, then "Foo Bar"
is concatenated 4 times.
My set up is below.
*Elasticsearch 1.0.0 on CentOs 6.4 with Java 1.7.0_51.*
*$ES_HOME/config/default-mapping.json:*
{
"_default_": {
"_all": {
"enabled": true,
"analyzer": "combo",
"store": false
},
"dynamic_templates": {
"string_multifield_template": {
"match": "*",
"match_mapping_type": "string",
"mapping": {
"include_in_all": false,
"fields": {
"{name}": {
"index": "not_analyzed",
"store": true,
"type": "string"
},
"lowercase": {
"analyzer": "lowercase",
"index": "analyzed",
"store": false,
"type": "string"
}
}
}
}
}
}
}
*$ES_HOME/config/elasticsearch.yml:*
...
index.analysis.analyzer.lowercase.type:custom
index.analysis.analyzer.lowercase.tokenizer: keyword
index.analysis.analyzer.lowercase.filter [ lowercase ]
index.analysis.analyzer.combo.type: custom
index.analysis.analyzer.combo.sub_analyzers:[ keyword, lowercase ]
index.analysis.analyzer.combo.deduplication: true
index.analysis.analyzer.combo.tokenstream_reuse: false
...
The aggregation query I use is the following:
{
"aggs": {
"_all": {
"terms": {
"field": "_all"
}
}
}
}
Thoughts?
--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elasticsearch+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/f9344d45-33e6-45eb-b193-fdf1d24ebc1b%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: alternating hits totals for subsequent requests
Take a look at the 'preference' property of the search request body. If > you use the user's session id as a custom string, it should prevent the > jumping around of values. > > Docs: > http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-request-preference.html > > Ahh...Good to know. Thank you! :-) -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/5408ad00-b74e-466b-a11c-becede51edea%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: alternating hits totals for subsequent requests
>
>
> This is something that shouldn't happen on a refreshed index. Could you
> run a refresh on the indices that have different counts per shard:
>
> curl -XPOST localhost:9200/${index_name}/_refresh
>
> And then show two responses to
> curl http://localhost:9200/${index_name}/_search
> that return different counts?
>
I did try a refresh via elasticsearch-head but it did not fix the problem
with the replicas.
> Regarding fixing, the easiest way would be to set the `number_of_replicas`
> setting to 0 and then back to its original value: this will deallocate
> replica shards and then allocate them again and they will get copied from
> the primaries.
>
I actually fixed it with the cluster move requests but this is good to know
too.
Thanks for the responses!
--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elasticsearch+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/1a8756d8-6029-4055-b5d9-bcabea59f16e%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: rebuilding replicas
> You can issue a Move allocation command of just the replicas. A single > move request with each of your replica shards shunted to a different node > should do it. The move is implemented as a copy from the primary (well it > is in ES 0.19 anyway) > > Note though that if you move things aroun such that a post move > auto rebalance dictates a shard replica to go back to where it was it > appears to then find the old copy and just reuse that data which cancels > out what you just tried to so. :) > Ahhh...so that's the trick. ;-) Well, it definitely wasn't obviously reading the API guide. Perhaps there should be a note there. ;-) I actually tried moving the primary which didn't change the replica, but I confirmed that moving the replica did rebuild it. MANY THANKS! -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/61b6aafa-3558-4626-b456-4b71d7b13579%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
rebuilding replicas
Is there a way via API to rebuild a replica other than just restarting the replica's node? If not, then I will submit a feature request. Somehow some of our replicas have different doc totals than their primaries, and I don't see a way to fix it via API. -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/9c64d53c-9fe0-412a-8056-b2d17c3ea59f%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: alternating hits totals for subsequent requests
Actually, I did indeed determine that for a few indexes there were different doc counts between some shards and their replicas. Under what circumstances could this happen, and what's the fastest/easiest way to correct this situation? On Wednesday, February 5, 2014 12:02:20 PM UTC-5, Adrien Grand wrote: > > > to make sure all your shards have the same number of documents (they may > however have different numbers of deleted documents, this is not a problem). > -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/31799376-685e-47a0-89f8-e066a86802ef%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: alternating hits totals for subsequent requests
We are definitely not performing any updates in parallel nor do we have any TTLs. Even if we did though, why would the counts alternate on subsequent requests? As far as plugins, we are using the analysis-phonetic plugin but considering this is a match_all query, I wouldn't think it would be a factor. How would I determine which index count is different? On Wednesday, February 5, 2014 11:44:16 AM UTC-5, Adrien Grand wrote: > > It shouldn't happen if you are not performing updates in parallel and > don't have documents with a TTL. Maybe you have a plugin that persists data > in an index that is taken into account when summing all hits in all > indices? (would be helpful to know the index which has changing counts). > -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/165f691b-03d5-4913-8949-4e45430d6f8f%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
alternating hits totals for subsequent requests
Why would I get a different alternating hits total for subsequent match_all search requests (i.e. curl http://localhost:9200/_search) with zero failed? i.e. The first time I get 8503251, the next time I get 8479263, the next time I get 8503251, the next time I get 8479263, and so on, and so on. My setup is the following: - ElasticSearch 0.90.7 with - 10 nodes (8 data + 1 primary master + 1 secondary master) - 35 indexes w/ 5 shards + 1 replica per index - CentOS 6.4 (64 bit) - Java 1.7.0_45 (64 bit). Thoughts? -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/93ec8afa-b728-4a6c-a506-288e6259f4ae%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
