-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Solidify the approach to allowing typeless requests on an index with a custom type. #37450
Comments
Pinging @elastic/es-distributed |
Pinging @elastic/es-search |
@jpountz I assigned this to you, but please feel free to ping me if we should find another owner. |
I looked into this over the past two weeks. Unfortunately I haven't been able to come up with an approach that would feel more solid. On the positive side over the months we have made more and more internal APIs typeless, such as moving from I will keep looking into it over the next weeks, but I don't expect big changes, rather small changes in the same spirit as the one mentioned above. |
Thanks @jpountz, that makes sense to me! I mentioned this earlier, but I am fairly concerned about the amount of complexity we've been introducing into the mapping code related to mixed typed and typeless APIs. I was wondering if there were some smaller-scale refactors we could do to clarify or unify the points where we're resolving |
This is currently only tested via REST tests. Closes elastic#37450
I've been thinking a bit more about this one recently. In general I like the current approach that resolves the type as high in the stack as possible a bit better as it makes things easier to reason about. Having it eg. in I'm leaning towards addressing this issue through testing. I've been reviewing places where we had gaps in testing. One clear one is MetaDataMappingService, which I tried to address via #40578. |
…lastic#40578) This is currently only tested via REST tests. Closes elastic#37450
…lastic#40578) This is currently only tested via REST tests. Closes elastic#37450
In #35790, we introduced support for making typeless API calls against an index with a custom type name. For example, given an existing index with type
my_type
, we allow new documents to be indexed using the typeless endpointindex/_doc/id
. This is functionality is important in supporting the move to typeless APIs, since many users are likely to be working with older indices that were created with a custom type.The approach in #35790 is fairly fragile, and we would like to step back and consider if there is something cleaner and more solid we could do instead. To help document the current implementation, here is the list of PRs associated with this work:
_doc
. Make typeless APIs usable with indices whose type name is different from_doc
#35790_doc
as a top-level key as typed calls. Treat put-mapping calls with_doc
as a top-level key as typed calls. #38032The text was updated successfully, but these errors were encountered: