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

Custom search attributes validation per store #4655

Merged
merged 1 commit into from
Jul 20, 2023

Conversation

rodrigozhou
Copy link
Contributor

@rodrigozhou rodrigozhou commented Jul 19, 2023

What changed?
Add custom search attributes validation to VisibilityStore interface, and implements ES constraints.

Why?
Each store can have different constraint that might reject the value when inserting.
Eg: In ES, dates can only be between 1970 and 2262.

How did you test it?

Potential risks

Is hotfix candidate?

@rodrigozhou rodrigozhou requested a review from a team as a code owner July 19, 2023 23:02
@rodrigozhou rodrigozhou requested review from alexshtin and yiminc July 19, 2023 23:02
@@ -95,6 +95,10 @@ var _ store.VisibilityStore = (*visibilityStore)(nil)
var (
errUnexpectedJSONFieldType = errors.New("unexpected JSON field type")

minTime = time.Unix(0, 0).UTC()
maxTime = time.Unix(0, math.MaxInt64).UTC()
maxStringLength = 32766
Copy link
Member

Choose a reason for hiding this comment

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

I think search attribute already has size limit of 2KB.

Copy link
Contributor Author

@rodrigozhou rodrigozhou Jul 20, 2023

Choose a reason for hiding this comment

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

Well, still better to have this already in place just in case in the future we (or an OSS user) change it limit.

Copy link
Member

Choose a reason for hiding this comment

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

Yes, storage specific validators should reflect all storage limitation. DC value can be changed.

}
}
if err != nil {
if ignoreInvalidValues {
Copy link
Member

Choose a reason for hiding this comment

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

It seems we should check ignoreInvalidValues before validation? What is the point of doing the validation then ignore it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For the case the task with bad value. We want to check and ignore the value if it's invalid.

@rodrigozhou rodrigozhou force-pushed the vis-per-store-validation branch from 9d40345 to 9cd238d Compare July 20, 2023 02:59
@rodrigozhou rodrigozhou requested a review from a team July 20, 2023 14:31
@rodrigozhou rodrigozhou force-pushed the vis-per-store-validation branch 2 times, most recently from 002a803 to 95088c7 Compare July 20, 2023 19:42
Copy link
Member

@alexshtin alexshtin left a comment

Choose a reason for hiding this comment

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

LGTM, and I would really like to see unit tests for the new validator and unit test in search attributes validator, which tests "integration" between new and old validators. Can be done in separate PR.

@rodrigozhou rodrigozhou force-pushed the vis-per-store-validation branch from 95088c7 to c3ede59 Compare July 20, 2023 20:13
@rodrigozhou rodrigozhou merged commit fc414a8 into temporalio:master Jul 20, 2023
@rodrigozhou rodrigozhou deleted the vis-per-store-validation branch July 20, 2023 21:03
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.

3 participants