[ZDT migration] support root field addition#179595
Conversation
|
/ci |
|
/ci |
|
Pinging @elastic/kibana-core (Team:Core) |
| } from '@kbn/core-saved-objects-server'; | ||
| import { | ||
| IndexMappingMeta, | ||
| IndexMapping, |
There was a problem hiding this comment.
NIT could be imported as a type
| }); | ||
| }); | ||
|
|
||
| it('combines the changes from the types and from the root fields', () => { |
There was a problem hiding this comment.
Could we test behavior when adding properties to existing root fields, e.g. references?
There was a problem hiding this comment.
Not sure exactly how to do given helpers are stubbed for those unit tests, but I added one in 54d89d8, is that what you had in mind?
TBH this additive mapping diff generation is kinda unnecessary, we could just push everything as long as we know at least one change was done, but now that we have it...
There was a problem hiding this comment.
Yes, that's what I had in mind. The test covers it, thanks!
|
I don't know the |
Mapping update check and doc migration check are independent ( FWIW (given I know this is the underlying question 😄) I decided to not change anything in the document update phase given that adding new root mappings can't alter the document's content or trigger a data transformation in any way (I know we're doing it for the v2 impl but afaik this is still unnecessary). We will eventually change this if one day we want to add new root mappings that are backfilled. EDIT: actually looking at the code, it does cause the migrator to enter the document update phase. But then no documents will be picked up given the query based on older model versions will not return any doc, so it's probably even better than not entering the phase. |
Actually, what if we wanted to update all SO docs based on a new root type that was already in use but not yet mapped? In |
That's the thing: I don't think that's a valid use case.
Because as previously said, we should never need to update / pickup types if only root fields changes, given they will never require a change in data. That's a mapping-exclusive operation. |
💚 Build Succeeded
Metrics [docs]
History
To update your PR or re-run it, just comment with: |
) ## Summary Align V2 behavior with ZDT after #179595 Under the assumption that whenever we want to add new root fields (e.g. [created_by](#179344)), we will systematically add mappings for them, we can skip the `updateAndPickupMappings` operation iif ONLY root fields' mappings have changed during an upgrade (aka if none of the SO types have updated their mappings). Up until now, the logic was updating ALL SO types whenever a `root` field was added / updated. This is expensive and unnecessary, and can cause a noticeable impact to large customers during migrations.
Summary
Fix #179258
Change the version compatibility and mapping generation (
checkVersionCompatibilityandgenerateAdditiveMappingDiff) of the ZDT migration algorithm to support the scenario were root fields are added (adding new fields to our base mappings)