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

Add filter value properties with explicit types. #29

Merged
merged 10 commits into from
Aug 23, 2020

Conversation

fitzoh
Copy link
Contributor

@fitzoh fitzoh commented Aug 20, 2020

As described in #27, the Honeycomb API currently fails to parse queries if a filter is sent with the wrong type in the JSON payload.

This PR adds new value_* options to the filter schema for each type in the Honeycomb API.
These properties are mutually exclusive with themselves and the original value field.

Feel free to either comment or edit @kvrhdn.
If you'd prefer to go with one of the other options enumerated in #27 that's fine too, just putting an option out there.

Fixes #27

Copy link
Contributor

@yvrhdn yvrhdn left a comment

Choose a reason for hiding this comment

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

Thanks for contributing this @fitzoh!. I'll check it out in more detail this evening / tomorrow.

honeycombio/data_source_query.go Show resolved Hide resolved
honeycombio/data_source_query.go Outdated Show resolved Hide resolved
honeycombio/data_source_query.go Show resolved Hide resolved
honeycombio/data_source_query.go Show resolved Hide resolved
Copy link
Contributor

@yvrhdn yvrhdn left a comment

Choose a reason for hiding this comment

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

LGTM! The code is clear and the test cases cover the new functionality.

I'll update the documentation in a bit.

honeycombio/data_source_query.go Outdated Show resolved Hide resolved
Type: schema.TypeString,
Description: "The value used for the filter. Use of the explicitly typed `value_*` variants is recommended until the honeycomb API is able to support type inference as initially described in https://github.com/kvrhdn/terraform-provider-honeycombio/issues/27.",
Optional: true,
},
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
},
Deprecated: "Use of attribute `value` is discouraged, prefer using the explicitly typed `value_*` variants instead",
},

We could set the Deprecated attribute to warn users when using value instead of value_*. But it feels a bit weird since we are not necessarily deprecating it...

This results in:

➜  terraform apply
data.honeycombio_query.query[2]: Refreshing state... [id=2435509962]
data.honeycombio_query.query[3]: Refreshing state... [id=1242873032]
data.honeycombio_query.query[1]: Refreshing state... [id=1329679303]
data.honeycombio_query.query[0]: Refreshing state... [id=2511879708]
honeycombio_board.board: Refreshing state... [id=rpAjr7deUcb]

Warning: Deprecated Attribute

  on main.tf line 17, in data "honeycombio_query" "query":
  17: data "honeycombio_query" "query" {

Use of attribute `value` is discouraged, prefer using the explicitly typed
`value_*` variants


Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Thoughts?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We might want to add that value won't work for non-string values

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't know, I'm starting to think it might make sense to just remove it for now since it's fundamentally broken for a common use case

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, I agree that if you are using value instead of value_string you're likely going to be making mistakes and there is no way for the provider to warn about this.
Since we are adding explicit types already I think it's best to go all the way and deprecate use of value. This will clearly nudge users to consider the type of value and hopefully use the correct value_* variant.

honeycombio/data_source_query.go Outdated Show resolved Hide resolved
honeycombio/data_source_query.go Outdated Show resolved Hide resolved
@yvrhdn
Copy link
Contributor

yvrhdn commented Aug 22, 2020

Hi @fitzoh, I think this is ready to merge (and release). Do you want to give the last commits I added a final review before merging?

@cah-andrew-fitzgerald
Copy link
Contributor

cah-andrew-fitzgerald commented Aug 22, 2020

Hi @fitzoh, I think this is ready to merge (and release). Do you want to give the last commits I added a final review before merging?

Added a couple explicit warnings around value breaking w/ non-string columns, I'll leave merging those at your discretion.

Other than that I'd say :shipit:

Also +1 for the list changes

@yvrhdn yvrhdn merged commit aa23fef into honeycombio:main Aug 23, 2020
@yvrhdn
Copy link
Contributor

yvrhdn commented Aug 23, 2020

Thanks again @cah-andrew-fitzgerald. I'll release this with v0.0.9 🚀

@fitzoh fitzoh deleted the explicit-filter-types branch August 23, 2020 01:29
@fitzoh
Copy link
Contributor Author

fitzoh commented Aug 23, 2020

And thank you for the cleanup/docs @kvrhdn

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Query values converted to strings
3 participants