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
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
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
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
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
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,
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:
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:
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
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
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
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
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
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
14 matches
Mail list logo
