Comments (11)
Hey @mattes
I did think about returning an error, however as in your example above it wouldn't really make sense as field "Bogus" does not doesn't have any errors; I know a technicality.
I will definitely take a look and see if I can't make it panic though as it's really a configuration error rather than a validation one.
The real question is should StructExcept() panic as well?
from validator.
My concern is that if someone changes Field
to FieldNew
or whatever and then uses FieldNew
later in the code, thinking it must be fine, because validator.StructXX
did not return anything, this will lead into vulns. In a perfect world, the developer would not forget to to update validator.Structxx
of course ...
So from my perspective it should def panic or return an error. I think a panic
works, an error
might be nicer to handle.
It would be super awesome, if there is a way to let the compiler find these issues, but I doubt it's possible.
from validator.
Besides this issue, kudos for this lib! Tried several ones. This one is by far the best I've seen!
from validator.
The real question is should StructExcept() panic as well?
I think so.
from validator.
Thanks @mattes glad you like the lib 😄
After a quick look I remember why I didn't add panicing in the first place; there is no guarantee validator will validate/hit all fields passed to StructPartial() or StructExcept() so keeping track if a field exists or not is a little problematic, let me explain:
// NOTE: this is a very simple use case I could have gotten into arrays and maps
// but this will suffice
type ContactInfo struct {
Phone string `validate:"required"`
Address string `validate:"required"`
}
type User struct {
ID int `validate:"required"`
FirstName string `validate:"required"`
LastName string `validate:"required"`
ContactInformation *ContactInfo `validate:"omitempty"` // optional
}
user := &User{
ID: 1,
FirstName: "Joey",
LastName: "Bloggs",
}
errs := validate.StructPartial(user, "ContactInformation.Phone", "ContactInformation.Address")
// errs will be nil and that's ok beacause ContactInfomation is optional
errs := validate.StructPartial(user, "ContactInformation.fwfwe", "ContactInformation.ewfwef")
// errs will also be nil even though the fields are bogus; validator stops at ContactInformation
// because it was told it's ok too
That's the dilemma I'm faced with and so initially decided it was the users responsibility, just like using SQL and adding an incorrect Field name to the database.
Without allot of preprocessing pre or post validation and allot of overhead I don't know of a good way to add this? I'm open to any ideas
from validator.
Perhaps I can make it a configuration option whether to check that fields exist and during dev mode it can be set to true catching any issues and in production be set to off; my main concern is the overhead of the check, but this would alleviate that.
this will probably take me a while to implement, but think I can make it work.
from validator.
I think we should differentiate between syntactically errors and actual value errors. The lib should first check, if the specified fields really exist and then in a second step apply all validation rules.
SQL will also decline the operation if there is an invalid field name.
Perhaps I can make it a configuration option
I think the syntax check should be mandatory.
from validator.
@mattes I may make it mandatory, but it will probably slow down validate.StructXXX by 2 - 3 times and increase memory allocations by the same.
but I will definitely be panicing when a field doesn't exist; I will look into implementing this within the next few weeks.
from validator.
Sounds good.
from validator.
sorry for the delay, I fully intend to implement this, just busy with work and other projects.
from validator.
OK so went pretty far down the rabbit hole with this one, been racking my brains on how to reconcile type interface and if a field exists.
Scenario
Let's say I had a field of type interface that was OK to be empty but otherwise filled with a struct, when the field was not populated I know of no way to check that the field exists because there is no type information associated with the interface field when not set.
I know it sounds like an outlandish scenario, however I have run into many scenarios like this while developing this package that I thought would never happen, but they do.
Conclusion
I think that this is an all or nothing issue because I cannot preclude the scenario from happening, I will keep this issue open for a while and try and figure something out but realistically can't see a way around the above issue.
Any thought's or help would be welcome.
from validator.
Related Issues (20)
- Can't validate both `keys` and the struct value of maps of structs
- StructPartial does not dive to slice of structs HOT 1
- Proposal: Support validator chaining
- Multiple validations at one time
- Bool to struct{} in iso codes
- Failing validation using the base64url tag
- SSN regex doesn't match the rest of the validation and is loose with formatting rules
- Add support for `errors.As`
- err.Translate(trans) only works if translator passed via param (go-playground/validator)
- Is is possible to check if an array is greater then 0 in required_if
- Is it possible to register custom validation function directly returning errors? HOT 1
- Support for mutually exclusive groups of validations chained with OR
- security: update mimetype dependency to new secure version
- Partial struct validation does not validate child structs HOT 1
- Validation failed url with required_without
- validator for IBAN HOT 4
- Missing FieldError.Field() and 'Key' in ValidationErrors Returned from Var() and ValidateMap()
- Github sponsorhip HOT 1
- Panic on max, min Validation Tag with struct Fields in Version v10.20.0 and above
- Add support for type-specific Validation based on Interface
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from validator.