Use tsdb's id in Engine tests#85055
Conversation
|
Pinging @elastic/es-analytics-geo (Team:Analytics) |
This should be enough to detect if tsdb's `_id` field mapper changes enough to cause trouble for `Engine`. I suspect that in the end we'll need something more like the changes that elastic#84996 did for RecoverySourceHandlerTests but that's a much bigger change that I'd prefer to hold back until we need it. If tsdb's `_id` field mapper changes enough to cause trouble for `Engine`.
| final Field uidField = new Field( | ||
| "_id", | ||
| id, | ||
| randomBoolean() ? ProvidedIdFieldMapper.Defaults.FIELD_TYPE : TsidExtractingIdFieldMapper.FIELD_TYPE |
There was a problem hiding this comment.
I'm thinking I should pick this up front rather than per document....
|
run |
|
run elasticsearch-ci/part-1 |
|
Well, this grew larger than I'd hoped. But it's still smaller than it'd be if we needed to use the whole parsing infrastructure. I'd like to try this for now and bite the bullet on the parsing infrastructure only if we need it. This should be enough to detect if the field changes in an incompatible way. |
henningandersen
left a comment
There was a problem hiding this comment.
LGTM.
I wonder if it will eventually bite us that the _ids do not conform to the field mapper. But we can tackle that when we have to.
I'm reasonably sure we'll have to, yeah. But this'll catch those cases at least. Which'll be better than flying blind until then. |
This should be enough to detect if tsdb's
_idfield mapper changesenough to cause trouble for
Engine. I suspect that in the end we'llneed something more like the changes that #84996 did for
RecoverySourceHandlerTests but that's a much bigger change that I'd
prefer to hold back until we need it. If tsdb's
_idfield mapperchanges enough to cause trouble for
Engine.