Do not skip custom validators if value is null and allowNull is true

[papb]

In 2013, the pull request #601 was created to resolve some issues such as #270.

@tremby said (source)

I'd like to see this implemented, but I don't think it should even be an option. If allowNull is true, clearly you want to allow null. If it's not null, only then should the other validations happen.

Five years later, I would like to respectfully disagree. It should be an (opt-out, of course) option. Below I will present a situation where the mandatory aspect of this change is preventing me from doing what I want.

My use case is that I want to allow null only in some cases. Therefore, neither "always" (accomplished with allowNull: true) nor "never" (accomplished by allowNull: false) suit me, and since PR #601 made this a definitive check, any attempt of providing custom validators don't work.

myField: {
  validate: {
    custom(value) {
      if (value === null && !foobar(this.otherField1, this.otherField2)) {
        throw new Error("myField can't be null when otherField1 and otherField2 satisfy property X");
      }
    }
  }
}

When I attempt to create the instance giving null to that field, my custom validator above does not execute at all, no matter what value allowNull is set to.

Therefore this should be an option instead of a forced behaviour.

[awdnf]

+1

[damianijr]

+1

[sushantdhiman]

I think atleast no validate state should not be tied to allowNull, validators defined on attribute must run

[dylandechant]

this also fits a use case i have

[papb]

After further thought on this issue and further investigations on sequelize's code:

Current sequelize behavior is as follows

If the value of an attribute is null, no validators defined on that attribute run at all. Also, in that case, if allowNull is false, a ValidationError is thrown.

How I think it should be

If the value of an attribute is null and allowNull is false, the behavior shouldn't change, i.e., no validators defined on that attribute should run at all and a ValidationError should be thrown. To me this makes sense because running any other validators would be a waste anyway, because the validation is already going to fail.

But if the value is null and allowNull is true:

• No built-in validators defined on that attribute should run, because none of the build-in validators make sense with a null value (so for this part, the behavior won't change).
• Custom validators defined on that attribute should run.

Because of the last bullet point, this change would consist of a breaking change, because a few people's code could start throwing ValidationErrors where they previously didn't. Regardless, in my humble opinion is this change is deserved, because the current behavior of unexpectedly ignoring user defined validators is very confusing and restrictive (as I can't define my conditional validation as I wanted in the original post).

I will open a PR implementing the above changes soon (including documentation changes, of course).

[dalepo]

I know I'm late for this, but I think this PR does not make any sense. If you have a special case to validate your own model, then treat it as a special case with a model validation.
This broke most of the models from our project, we have around ~150 models. Because of this, we probably did a mistake on upgrading to v5.

[papb]

Hi @dalepo, I'm sorry to hear that...

Would you be willing to update your validators or will you end up rolling back to v4?

As I said in the upgrade guide:

To avoid problems when upgrading, please check all your custom validators defined per attribute, where allowNull is true, and make sure all these validators behave correctly when the value is null.

In other words, you can upgrade by adding a if (value === null) return; in the first line of each of your validators... 150 is a lot though, I feel your pain... Good luck.

[dalepo]

Hi @papb we probably are gonna roll back.

Adding if (value === null) return; would be a good solution, but sadly these functions are used in other modules and tests.
That or probably do a wrapper for each function.