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

types: Support Set and SetType #126

Merged
merged 9 commits into from
Sep 14, 2021
Merged

types: Support Set and SetType #126

merged 9 commits into from
Sep 14, 2021

Conversation

bflad
Copy link
Contributor

@bflad bflad commented Sep 2, 2021

Closes #53

@bflad bflad added the enhancement New feature or request label Sep 2, 2021
@bflad bflad added this to the v0.4.0 milestone Sep 2, 2021
@bflad bflad self-assigned this Sep 2, 2021
bflad added a commit that referenced this pull request Sep 3, 2021
@bflad
Copy link
Contributor Author

bflad commented Sep 3, 2021

I'm going to let things settle with #24, #127, and #128 (all v0.3.0 candidates) before continuing here, personally.

bflad added a commit that referenced this pull request Sep 7, 2021
This initial copy does not include a real set implementation or handling for duplicate elements, however this sets the stage for expanding testing to cover the use case.
@bflad bflad marked this pull request as ready for review September 9, 2021 23:47
@bflad bflad requested a review from a team September 9, 2021 23:47
@bflad bflad removed their assignment Sep 9, 2021
@bflad
Copy link
Contributor Author

bflad commented Sep 10, 2021

My upfront guess is that this implementation may need to change into allowing duplicates by overwriting existing elements during Set() and SetAttribute() calls instead of returning a duplicate set element validation error. I guess we will want to decide on what the more correct behavior should be -- potentially allowing silently successful duplicates where they may not be intended or potentially causing unnecessary errors with provider implementations that will want the type to just consolidate data automatically.

My first impression is that the current implementation may actually be desirable in this case (and allow the implementation to be much simpler) since practitioners would receive configuration validation errors for duplicate set elements and API fields this is being used against shouldn't have duplicates if this attribute type is being chosen.

I'm not sure if its worth capturing this context anywhere (maybe on the Set/SetType documentation) no matter which way we decide to go.

Edit: As I reread this after submitting it, I'm not exactly sure how we could properly deduplicate only on Set()/SetAttribute() unless we provided some flag to switch the reflection behavior and passed that all the way through. To that end, I'm slightly more convinced this initial implementation may be desirable or we will really need to make some more invasive changes to the framework type handling.

Copy link
Contributor

@paddycarver paddycarver left a comment

Choose a reason for hiding this comment

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

Looks good. Some small additions I recommended, and looks like some typos in some tests.

types/set.go Outdated Show resolved Hide resolved
types/set.go Outdated Show resolved Hide resolved
types/set.go Show resolved Hide resolved
types/set.go Show resolved Hide resolved
types/set.go Show resolved Hide resolved
types/set_test.go Show resolved Hide resolved
types/set_test.go Show resolved Hide resolved
Copy link
Contributor

@paddycarver paddycarver left a comment

Choose a reason for hiding this comment

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

Yeah, let's do it. Good work! 👍 🚀

@bflad bflad merged commit b0e3081 into main Sep 14, 2021
@bflad bflad deleted the bflad-types-Set branch September 14, 2021 13:02
@github-actions
Copy link

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Define Set type
2 participants