Skip to content
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

Introduce error reporting in schema #3790

Merged
merged 1 commit into from
Mar 27, 2017

Conversation

ruflin
Copy link
Contributor

@ruflin ruflin commented Mar 22, 2017

Currently in schema errors are only reported through logging which makes testing difficult. This PR introduces the collection of errors during applying the schema.

Now Apply returns a list of errors. Currently these are ignored to keep the same implementation as before. Over time this should be adjusted to handle errors correctly. Logging in the schema should be remove and moved up to the Metricsets itself.

This change should also simplify testing of different versions in unit tests, as schema.Apply will return errors. Currently this check is done in the system tests checking the log itself which is not very efficient.

ApplyNoError was introduced as a temporary workaround for the processors implementation.

This is part of #3807

@ruflin ruflin added discuss Issue needs further discussion. Metricbeat Metricbeat labels Mar 22, 2017
logp.Err("%s", err)
errs := multierror.Errors{}
errs = append(errs, err)
return errs
Copy link
Contributor

@tsg tsg Mar 22, 2017

Choose a reason for hiding this comment

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

Could these lines be written as return multierror.Errors{err}? Would be nicer if it works.

@tsg
Copy link
Contributor

tsg commented Mar 22, 2017

I like the idea. Generally I'd suggest making this be the Apply method to keep the interface clean and just ignore the errors for now in all the modules where we don't yet care about the answer. In that case, each module needs an update, but the change is minimal.

type Error struct {
key string
message string
errorType int
Copy link
Contributor

@tsg tsg Mar 24, 2017

Choose a reason for hiding this comment

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

Would it make sense to make ErrorType a type so that it's restricted to the consts above?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

@ruflin ruflin force-pushed the schema-apply-returns-errors branch from 3fddd75 to 6dd996a Compare March 24, 2017 13:01
@ruflin ruflin changed the title Proposal: Introduce error reporting in schema Introduce error reporting in schema Mar 24, 2017
Currently in schema errors are only reported through logging which makes testing difficult. This PR introduces the collection of errors during applying the schema.

Now Apply returns a list of errors. Currently these are ignored to keep the same implementation as before. Over time this should be adjusted to handle errors correctly. Logging in the schema should be remove and moved up to the Metricsets itself.

This change should also simplify testing of different versions in unit tests, as `schema.Apply` will return errors. Currently this check is done in the system tests checking the log itself which is not very efficient.

ApplyNoError was introduced as a temporary workaround for the processors implementation.

This is part of elastic#3807
@ruflin ruflin force-pushed the schema-apply-returns-errors branch from 6dd996a to 1a53e73 Compare March 24, 2017 13:02
Copy link
Contributor

@tsg tsg left a comment

Choose a reason for hiding this comment

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

LGTM.

@ruflin ruflin added review and removed discuss Issue needs further discussion. labels Mar 25, 2017
@exekias exekias merged commit 0288d2b into elastic:master Mar 27, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants