Skip to content

Allow to override attributes from external fields#575

Merged
jsoriano merged 3 commits intoelastic:masterfrom
jsoriano:override-external-fields
Nov 10, 2021
Merged

Allow to override attributes from external fields#575
jsoriano merged 3 commits intoelastic:masterfrom
jsoriano:override-external-fields

Conversation

@jsoriano
Copy link
Copy Markdown
Member

@jsoriano jsoriano commented Nov 9, 2021

Attributes defined in the fields definition are combined with the imported field, with some exceptions:

  • external is removed, as it doesn't make sense in the final definition.
  • type is always used as defined in the imported field, to avoid having ECS fields with different types.

Some use cases:

Fixes #392
Fixes elastic/package-spec#247

@jsoriano jsoriano added the Team:Ecosystem Label for the Packages Ecosystem team label Nov 9, 2021
@jsoriano jsoriano requested review from a team and andrewkroh November 9, 2021 19:34
@jsoriano jsoriano self-assigned this Nov 9, 2021
@jsoriano jsoriano changed the title Allow to override external fields Allow to override attributes from external fields Nov 9, 2021
@elasticmachine
Copy link
Copy Markdown
Collaborator

elasticmachine commented Nov 9, 2021

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS
Pipeline View Test View Changes Artifacts preview preview

Expand to view the summary

Build stats

  • Start Time: 2021-11-10T11:53:07.615+0000

  • Duration: 35 min 12 sec

  • Commit: 095d0ca

Test stats 🧪

Test Results
Failed 0
Passed 452
Skipped 4
Total 456

🤖 GitHub comments

To re-run your PR in the CI, just comment with:

  • /test : Re-trigger the build.

@@ -145,8 +145,12 @@ func (dm *DependencyManager) injectFieldsWithRoot(root string, defs []common.Map
}

transformed := transformImportedField(imported)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if it isn't possible to sketch the implementation without involving the DeepUpdate method (less error-prone code).

For example:

base := def
base.Delete("external")
transformed := transformImportedField(base, imported)

Function transformImportedField can create new base struct if it's nil.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will give a try, but this code would modify the definition, and I wanted to avoid this. For that we need a way to clone it and use as the base struct, or to deep update the final map.
Would you prefer clone over deep update?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just wouldn't like to add more potentially error-prone methods to mapStr, but if you feel confident the function maybe it's worth leaving it as is.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I copied it from libbeat where it has served well for years 🙂

Maybe in the future we can refactor these methods to use FieldDefinitions instead of mapStrs.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I remember that Stefen strongly recommended not to use mapStr anymore :)

Anyway, I see that you covered this part with tests, so it shouldn't be a big unknown. Let's not elongate the discussion.

if err != nil {
return nil, errors.Wrap(err, "can't import field")
}
f.Type = imported.Type
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: WDYT about introducing a new method to extract these if-conditions? For example: f.Update(imported)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea 👍

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 095d0ca.

Though doing it as a method of the FieldDefinition implies to do it for all its attributes, including the sub-fields. I have implemented this part by updating sub-fields with the same name, and appending the rest.

An alternative could have been to extract these if-conditions in a method here, not as a method of the struct, and then I could only update the fields relevant here.

Let me know what you think.

// via DeepUpdate.
// DeepUpdateNoOverwrite is a version of this function that does not
// overwrite existing values.
func (m MapStr) DeepUpdate(d MapStr) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wish the DeepUpdate isn't mandatory in this implementation :)

}

func (orig *FieldDefinition) Update(fd FieldDefinition) {
if fd.Name != "" {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, so just have to remember about updating these conditions when adding a new property to the FieldDefinition.

I'm curious if it isn't shorter to use the YAML marshaller to update fields.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, so just have to remember about updating these conditions when adding a new property to the FieldDefinition.

Yes, but well, having it close to the struct I guess that this is easier.

I'm curious if it isn't shorter to use the YAML marshaller to update fields.

I can give a try to this if prefered. Not sure if we will have flexibility on the nested fields, but we could keep this part as is.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't want to slow you down with this as this is a working implementation. We can come back to this in the future.

@mtojek mtojek self-requested a review November 10, 2021 12:19
Copy link
Copy Markdown
Contributor

@mtojek mtojek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM if the CI is happy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Team:Ecosystem Label for the Packages Ecosystem team

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Change Proposal] Support external fields as dimensions Allow adding attributes to external field definitions

3 participants