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

_routing in child type mapping prevents indexing #1738

Closed
kevingessner opened this issue Feb 24, 2012 · 5 comments
Closed

_routing in child type mapping prevents indexing #1738

kevingessner opened this issue Feb 24, 2012 · 5 comments
Labels

Comments

@kevingessner
Copy link

It appears that the child document's routing value is, by default, its parent's ID. Thus, if the parent has a _routing path set in its mapping, the child and parent will be mapped to different shards (which is bad).

Adding _routing to the child mapping does not help, as the value from the document does not override the default routing value (i.e. the parent's ID). Instead, it causes an exception while indexing the child document.

Reproduced in 0.19.0.RC3: https://gist.github.com/1902998

@kimchy
Copy link
Member

kimchy commented Feb 26, 2012

Yea, at least for now you need to explicitly pass the routing value (which is a good practice if you can). It happens because setting the parent automatically set the routing value when indexing, so it does not go and tries to extract the routing value from the actual document.

@spinscale
Copy link
Contributor

still the same behaviour with 1.2, quick reproduction with sense

DELETE test
PUT test

PUT /test/parent/_mapping
{
  "parent": {
    "_routing": {
      "required": true,
      "path": "account"
    }
  }
}

PUT /test/child/_mapping
{
  "child": {
    "_parent": {
      "type": "parent"
    },
    "_routing": {
      "required": true,
      "path": "account"
    }
  }
}

# error returned
PUT /test/child/c1?parent=p1
{
    "account": 1
}

# no error
PUT /test/child/c2?parent=p1&routing=1
{
    "account": 1
}

@clintongormley
Copy link
Contributor

@spinscale perhaps close this in favour of #6730?

@spinscale
Copy link
Contributor

if we decide to leave things as as they are now, this still needs to be fixed - and/or we could do it before 2.0 :-)

@clintongormley
Copy link
Contributor

Closed in favour of #6730

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants