StructPartial() doesn't complain about invalid fields about validator

[deankarn]

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?

[mattes]

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.

[mattes]

Besides this issue, kudos for this lib! Tried several ones. This one is by far the best I've seen!

[mattes]

The real question is should StructExcept() panic as well?

I think so.

[deankarn]

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

[deankarn]

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.

[mattes]

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.

[deankarn]

@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.

[mattes]

Sounds good.

[deankarn]

sorry for the delay, I fully intend to implement this, just busy with work and other projects.

[deankarn]

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.