validateNumericality didn't test if attributes value is a number
only if it's type is number.
Further nullCheck had a wrong testing order. It first checked if
value is null, later if blank. Also null check only used two equals,
not three. We don't use blank() anymore, testing if variable is
undefined should be fine too.
Added tests covering validateNumericality.
- validateUpsert:true reports validation errors back to the callback
- validateUpsert:false does not call `isValid()` at all
- any other value report validation errors via `console.warn`
When a required number property is set to NaN, for example as a result
of coersion (`Number([1,2,3])`), the "presence" validation now correctly
reports an error.
Fix the implementation of updateOrCreate (a.k.a. upsert) to validate
the model before calling the connector.
In order to preserve backwards compatibility, validation errors are
only logged via console.warn by default.
The correct behaviour, where validation errors fail the updateOrCreate
operation, can be enabled via new model setting "validateUpsert".
Return the raw object data when running on Node v0.11.14+
That way all `inspect` options are always preserved.
When running on older version:
- Honour the depth argument passed to the custom `inspect` function.
- Disable color output, becase there is now way how to detect whether
colors were enabled or disabled by the top-level caller.
When building a list of errors for `ValidationError.message`, include
the values of invalid properties too.
In order to keep the message reasonably short, the values are truncated
at approx 32 characters.
If the validator configured with `{async:true}` option and `if/unless`
condition, validator should be skipped when the condition is un-fulfilled,
so the validator should be pass.
But currently, when skipping the validator, it calls `done(true)` which
accepts a `fail` flag as a param, this will fail the entire validation.
Signed-off-by: Clark Wang <clark.wangs@gmail.com>
Previously validations were appended to an array when configured. The
format was cumbersome, and led to issues. This refactors the
configuration into an object, as a property of the Model.
Note that if no validations have been configured, this property is
currently `undefined`.
Modify ValidationError constructor to include the model name and
a human-readable representation of the validation errors (messages)
in the error message.
Before this change, the message was pointing the reader
to `err.details`. Most frameworks (e.g. express, mocha) log only
`err.message` but not other error properties, thus the logs were
rather unhelpful.
Example of the new error message:
The `User` instance is not valid. Details: `name` can't be blank.
Modify the "unique" validator to accept additional property names to
narrow the space of rows searched for duplicates.
Example:
Consider `SiteUser` belongsTo `Site` via `siteId` foreign key.
Inside every site, the user email must be unique. It is allowed to
register the same email with multiple sites.
SiteUser.validateUniquenessOf('email', { scopedTo: ['siteId'] });
- change `statusCode` from 400 to 422
- nest `context` and `codes` inside `details`
- add `details.messages`
- reword the main error message
Remove the call to Error's constructor from ValidationError constructor,
because it's a no-op - Error's constructor creates a new
instance when called via `.call()`.
Miroslav Bajtoš
Amir Jafarian
CerealGuy
RobinBiondi
Ryan Graham
Fabien Franzen
Miroslav Bajtoš
James Billingham
Clark Wang
Raymond Feng
Anatoliy Chakkaev