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

"copy_to" behaviour in nested fields doesn't match the mapping #6701

Closed
tstibbs opened this Issue Jul 3, 2014 · 5 comments

Comments

Projects
None yet
5 participants
@tstibbs
Copy link
Contributor

tstibbs commented Jul 3, 2014

I have a nested field, containing some fields with the 'copy_to' attribute. I index a document. Then, I look at the mappings - these show the 'copy_to' field as appearing in the root object, not the nested objects.

(See https://gist.github.com/tstibbs/dc36483f96f8d1471385 for the necessary commands to reproduce.)

However, the fields appear to be copied into the 'copy_to' field in the nested object.

If the 'copied' field is created in the root object, the following query should return my document (but it doesn't):

{
  "query": {
    "bool": {
      "must": [
        {
          "match" : {
            "copied" : "rover"
          }
        },
        {
          "nested": {
            "path": "children",
            "score_mode": "avg",
            "query": {
              "match": {
                "colour": "red"
              }
            }
          }
        }
      ]
    }
  }
}

If the 'copied' field is created in each child, then following query should match (it does):

{
  "query": {
    "nested": {
      "path": "children",
      "score_mode": "avg",
      "query": {
        "bool": {
          "must": [
            {
              "match": {
                "copied": "rover"
              }
            },
            {
              "match": {
                "colour": "red"
              }
            }
          ]
        }
      }
    }
  }
}

To me, the current behaviour makes sense - the fields are copied to a field within the item itself. However, I think the issue is that the mapping doesn't match the behaviour, and the documentation doesn't specify which is correct.

So, I can't currently use this feature, because I don't know which issue is the bug!

@clintongormley

This comment has been minimized.

Copy link
Member

clintongormley commented Jul 25, 2014

I think that copying to field foo, then that field should be in the main document, but copying to field some.nested.path.foo should create that field in the nested document.

@tstibbs

This comment has been minimized.

Copy link
Contributor Author

tstibbs commented Jul 25, 2014

I agree.

Being able to copy to a field within the nested document is very useful because it allows us to get around the fact that the _all field is only on the root object.

@tstibbs

This comment has been minimized.

Copy link
Contributor Author

tstibbs commented Jul 25, 2014

Actually, your suggestion is more or less the current behaviour (I hadn't thought of specifying the full path). If give the full path (children.copied in my example) then the field does get indexed in the child and the mapping shows it in the correct place.

So actually, I guess the only bug is that it puts the value in the child even when you tell it to put it in the parent.

@jpountz jpountz removed the adoptme label Jul 25, 2014

@clintongormley clintongormley removed the adoptme label Jul 25, 2014

jpountz added a commit to jpountz/elasticsearch that referenced this issue Jul 29, 2014

Mappings: Fix `copy_to` behavior on nested documents.
Today, `copy_to` always copies a field to the current document, which is often
wrong in the case of nested documents. For example, if you have a nested field
called `n` which has a sub-field `n.source` whose content should be copied to
`target`, then the latter field should be created in the root document instead
of the nested one, since it doesn't have `n.` as a prefix. On the contrary, if
you configure the destination field to be `n.target`, then it should go to the
nested document.

Close elastic#6701

@jpountz jpountz closed this in 99b3290 Aug 1, 2014

jpountz added a commit that referenced this issue Aug 1, 2014

Mappings: Fix `copy_to` behavior on nested documents.
Today, `copy_to` always copies a field to the current document, which is often
wrong in the case of nested documents. For example, if you have a nested field
called `n` which has a sub-field `n.source` whose content should be copied to
`target`, then the latter field should be created in the root document instead
of the nested one, since it doesn't have `n.` as a prefix. On the contrary, if
you configure the destination field to be `n.target`, then it should go to the
nested document.

Close #6701

@jpountz jpountz removed bug labels Aug 1, 2014

jpountz added a commit that referenced this issue Sep 8, 2014

Mappings: Fix `copy_to` behavior on nested documents.
Today, `copy_to` always copies a field to the current document, which is often
wrong in the case of nested documents. For example, if you have a nested field
called `n` which has a sub-field `n.source` whose content should be copied to
`target`, then the latter field should be created in the root document instead
of the nested one, since it doesn't have `n.` as a prefix. On the contrary, if
you configure the destination field to be `n.target`, then it should go to the
nested document.

Close #6701
@apatrida

This comment has been minimized.

Copy link
Contributor

apatrida commented Jan 21, 2015

And it never was really clear what the final behaviour should be with nested docs, nor is it in the documentation. Is the full path required to get the field into child, without path does it go to parent?

@clintongormley

This comment has been minimized.

Copy link
Member

clintongormley commented Jan 21, 2015

@jaysonminard The full path is required to get the field into the nested doc. This will become more obvious when we start requiring the full path for all fields, as in #8872

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.