You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've noticed an issue that either points to me misunderstanding something about routing in Elasticsearch or a subtle bug in elasticsearch itself. Here's what I'm trying to do:
create an alias with a routing parameter and a term filter ( following the single index + routing idea for multi-user indices)
When trying to create aliases, we noticed that the routing parameter was getting dropped from our alias's definition. Since we put documents into the index with the routing param, but only query using the alias, documents weren't getting returned most of the time even if they were in the index.
Upon debugging, we found that the POST _aliases endpoint silently drops the routing parameter if it's an integer, but honors it if it's a string. Oddly, though, the PUT endpoint to create a single alias works for a string or numeric routing param.
Here's the ruby program we initially used to debug inside the Rails console (easier to change the routing param from int to string - i just cut & pasted the curl commands from our logging there. Guess I could set an ENV var for the shell stuff, but I leave that to the user 😄 )
Hi there,
I've noticed an issue that either points to me misunderstanding something about routing in Elasticsearch or a subtle bug in elasticsearch itself. Here's what I'm trying to do:
When trying to create aliases, we noticed that the routing parameter was getting dropped from our alias's definition. Since we put documents into the index with the routing param, but only query using the alias, documents weren't getting returned most of the time even if they were in the index.
Upon debugging, we found that the POST _aliases endpoint silently drops the routing parameter if it's an integer, but honors it if it's a string. Oddly, though, the PUT endpoint to create a single alias works for a string or numeric routing param.
See the test case below.
Our ES version we're testing against:
curl -XGET 'http://localhost:9200'
which returns:
Here's the ruby program we initially used to debug inside the Rails console (easier to change the routing param from int to string - i just cut & pasted the curl commands from our logging there. Guess I could set an ENV var for the shell stuff, but I leave that to the user 😄 )
The text was updated successfully, but these errors were encountered: