-
Notifications
You must be signed in to change notification settings - Fork 1.4k
V6 development #114
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
V6 development #114
Conversation
investigation if goroutines in a consumer producer pattern vs passing a map Spoiler: the map wins out big time!
…or.v5 into v5-development
whether it's a struct field or just a regular field working on a single function to handle both to reduce checking the same values within struct field recursion or a regular field; this will also help reduce code complexity and keep things DRY.
V5 development
updated baked in functions: hasLengthOf isGt isGte isLt isLte to use utf8.RuneCountInString for string length comparisons, not counting multi-bye characters but runes in string length comparisons.
update to use utf8.RuneCountInString for string length
update string comparisons to use utf8.RuneCountInString
initial function layouts and validation completed, still need to rework all of the baked in functions, add map and array traversal and add back original test cases. NOTE: a far more pragmatic validation tests will be added, but not until it has been proven stable with at least the old tests.
added single field validation function. updated a few more baked in functions. added back single field validation benchmark.
completed all validations function conversion. updated omitempty check to continue if all ok instead of passing tag to be validated.
updating test for the new error return formet updated assertion functions to handle a nil Map,Slice,Ptr.....type fixed hasValue check not comparing Interface but field Value.
Updated all tests to comply with new api. Fix a few bugs found with validation.
Renamed for better clarity. Added Field OrTag Benchmark.
was just keeping around for reference when converting.
when no errors occur, let's reuse the existing object.
now the benchmarks are getting back to awesome!
| included within the parameter i.e. excludesall=| you will need to use the UTF-8 hex | ||
| representation 0x7C, which is replaced in the code as a pipe, so the above will | ||
| become excludesall=0x7C | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was this paragraph supposed to replace the one above ("NOTE2: comma is the default separator of validation tags")? Reading through the current docs, it is hard to understand which of , or | is the default separator.
Comma (",") is the default separator of validation tags. If you wish to
have a comma included within the parameter (i.e. excludesall=,) you will need to
use the UTF-8 hex representation 0x2C, which is replaced in the code as a comma,
so the above will become excludesall=0x2C.type Test struct { Field `validate:"excludesall=,"` // BAD! Do not include a comma. Field `validate:"excludesall=0x2C"` // GOOD! Use the UTF-8 hex representation. }Pipe ("|") is the default separator of validation tags. If you wish to
have a pipe included within the parameter i.e. excludesall=| you will need to
use the UTF-8 hex representation 0x7C, which is replaced in the code as a pipe,
so the above will become excludesall=0x7Ctype Test struct { Field `validate:"excludesall=|"` // BAD! Do not include a a pipe! Field `validate:"excludesall=0x7C"` // GOOD! Use the UTF-8 hex representation. }
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks @tschaub I'll correct the docs; next time if you could create a new issue that'd be great as it's confusing to have a discussion in a closed or merge issue/PR :)
V6 development
No description provided.