Add model validations option#640
Merged
sdepold merged 7 commits intosequelize:masterfrom May 24, 2013
tremby:model-validations
Merged
Add model validations option#640sdepold merged 7 commits intosequelize:masterfrom tremby:model-validations
sdepold merged 7 commits intosequelize:masterfrom
tremby:model-validations
Conversation
The existing but unused (as far as I could tell) DAO option `validate`
can now have member methods which will be called with the model object's
context after the other (field-specific) validations.
Only custom functions are allowed (since isInt etc wouldn't make sense
in this context).
As with other custom validations, they are deemed to pass if they throw
no error, or fail if an error is thrown.
Any error messages collected are added to a '_' member array of the
validation result object, alongside the arrays named after any fields
whose validations failed.
Example:
var Pub = Sequelize.define('Pub', {
name: { type: Sequelize.STRING },
address: { type: Sequelize.STRING },
latitude: {
type: Sequelize.INTEGER,
allowNull: true,
defaultValue: null,
validate: { min: -90, max: 90 }
},
longitude: {
type: Sequelize.INTEGER,
allowNull: true,
defaultValue: null,
validate: { min: -180, max: 180 }
},
}, {
validate: {
xorCoords: function() {
if ((this.latitude === null) === (this.longitude === null)) {
throw new Error('Require either both latitude and longitude or neither')
}
}
}
})
In this simple case an object fails validation if latitude or longitude
is given, but not both. If we try to build one with an out of range
latitude and no longitude, `raging_bullock_arms.validate()`, might
return
{
'latitude': ['Invalid number: latitude'],
'_': ['Require either both latitude and longitude or neither']
}
A test is included.
As discussed on IRC. Also add task for 2.0 to change the validate() output structure.
Member
|
upvote for replacing __model with the actual custom validation's name |
Instead of a hash called __model with the model validation errors, the
model validation errors are now alongside the field validation keys of
the hash, named after the validation's key in the validate array. To be
as consistent as possible, the value is an array even though it will
only ever have one member. The structure is set to change in 2.0.
Example: where there was a model validation set up like
validate: {
xnor: function() {
if (this.field1 === null) === (this.field2 === null) {
throw new Error('require both or neither')
}
}
}
and field1 and field2 have some validations, validate() might return
something like
{
field1: [
'must be an email address',
'email address must be @example.com'
],
xnor: ['require both or neither']
}
…to DAO factory Also add a test for it
Plus a test for that
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
As discussed on IRC tonight...
The existing but unused (as far as I could tell) DAO option
validatecan now have member methods which will be called with the model object's context after the other (field-specific) validations.Only custom functions are allowed (since isInt etc wouldn't make sense in this context).
As with other custom validations, they are deemed to pass if they throw no error, or fail if an error is thrown.
Any error messages collected are added to a '_' member array of the validation result object, alongside the arrays named after any fields whose validations failed.
Example:
In this simple case an object fails validation if latitude or longitude is given, but not both. If we try to build one with an out of range latitude and no longitude,
raging_bullock_arms.validate()might returnA test is included.