Data Validation #
One common requirement when you are managing data is to perform data validation. In real world applications you may need to check that any newly created or updated document meet a certain criteria.
A common example is email validation. Let's say you have developed a registration page where you request a user's name and email and you want to ensure that the email they provide is valid.
With Kuzzle, instead of programming the validation logic yourself, you can pick from a set of predefined validation patterns. Validations are defined in a validation schema which determines what pattern is linked to what field, every time Kuzzle receives input data, it checks this validation schema and returns an error if a validation pattern fails. The validation schema can be configured in the validation
field of the configuration file.
For a detailed look at data validation, please refer to our Data Validation Reference.
You can bypass data validation by using bulk:write or bulk:mWrite actions.
Basic Validation #
A validation schema is defined using a hierarchical structure that contains a set of rules within an index, collection, and document field.
For example, below is a validation schema for the onlineshop
index and products
collection that defines the validation pattern for field price
and field productDescription
:
{
"validation": {
"onlineshop": {
"products": {
"fields": {
"price": {
"type": "number",
"mandatory": true
},
"productDescription": {
"type": "string",
"defaultValue": "Sorry, no description available for this product."
}
}
}
}
}
}
Let's take a look at what this validation schema does:
- It defines a set of rules for documents in the
products
collection of theonlineshop
index. - It ensures that
price
exists and is aNumber
. - It ensures that
productDescription
is aString
and has a value when none is provided.
For a complete list of validation patterns please refer to our Validation Patterns Reference.
Type Options #
Type Options can be used to provide advanced validation of certain fields. These are only available for some field types.
Below is an example of how the range
type option is used to ensure that the field price
is greater than zero:
{
"validation": {
"onlineshop": {
"products": {
"fields": {
"price": {
"type": "number",
"mandatory": true,
"typeOptions": {
"range": {
"min": 0
}
}
},
"productDescription": {
"type": "string",
"defaultValue": "Sorry, no description available for this product."
}
}
}
}
}
}
For more information regarding Type Options, please refer to this section of the Data Validation Reference.
Advanced Validation #
If the basic validation functionality doesn't meet your requirements, you can take advantage of Koncorde to create complex validation specifications.
Koncorde is the same component used to create real-time subscriptions.
The idea is simple: use Koncorde to specify a filter that can be used to validate documents. For example, here we ensure that at least one of the fields price
or vatPrice
exists by placing a filter in the validators
field of the validation schema:
{
"validation": {
"onlineshop": {
"products": {
"fields": {
"price": {
"type": "number",
"typeOptions": {
"range": {
"min": 0
}
}
},
"vatPrice": {
"type": "number",
"typeOptions": {
"range": {
"min": 0
}
}
},
"productDescription": {
"type": "string",
"defaultValue": "Sorry, no description available for this product."
}
},
"validators": [
// Here goes the filters
{
"or": [
{
"exists": {
"field": "price"
}
},
{
"exists": {
"field": "vatPrice"
}
}
]
}
]
}
}
}
}
In the example above, we used both the exists
operator and the or
operator to build our validation rule. For more information take a look at our Koncorde Reference.