Validating Data with Triggers in a NoSQL Database

NoSQL provides you with a framework where you have complete schema flexibility and you are free to decide your own data model. Complete flexibility offers so much that it’s also easy to make a mistake such as adding a Product JSON document into a Customer Collection. Yikes!

Corralling this much flexibility can be useful as noted in an article written under the heading Triggers in a .NET NoSQL Database. The article did an awesome job presenting a basic use case to validate data with Triggers, which I build upon in this document.  Here I present a ‘customizable Triggers application’ for you to download. It is presented under the Apache 2.0 License.

What you get with the Download?

The download contains two different projects namely, ValidationThroughTriggers and ClientAPP from here: ValidationThroughTriggers.zip

ValidationThroughTriggers Project

This is the main project for implementation of triggers to be deployed for JSON Schema validation. There are three important parts of this project needed to effectively use and customize the application:

ValidationThroughTriggers Class

This class implements the IDatabaseTrigger interface which is available in the namespace Alachisoft.NosDB.Common.Triggers. For reference here is the PreTrigger method implementation:

Rules Folder

The rules folder contains the code, in terms of classes, which verifies the integrity of documents maintained in this folder. They all implement the IValidationRule interface. The following rules files are defined:

  • AllowedValuesRule.cs
  • AttributeExistenceRule.cs
  • DataTypeRule.cs
  • DefaultValueRule.cs
  • RangeRule.cs

You can add more rules to customize the application for your use case.

Constraints.conf File

The constraints which you need to validate in Pre-Trigger are defined in this file. You can always customize this code to suit your needs, but the current implementation of PreTrigger will support the following constraints.

Attribute

When you define an attribute in the “Constraints.conf” file then the document must contain this value. It can be defined like

Data-Type

The data-type constraint allows you to restrict the value of an attribute to a specific data type. For example, age can be restricted to be an integer. If you do not define the data-type of an attribute, you can insert any data type value against it. The supported data types in this application are string, int32, int64, double, decimal and datetime. The data-type constraint can be defined like:

Default-Value

If the attribute you defined in the constraints file and doest not exist in the document, then a default-value is added to make it valid for storage. In case default-value is not provided and the document does not contain the attribute then it gets rejected. The default-value can be defined like:

Allowed-Values

If allowed-values are specified against an attribute, the attribute cannot accept any value other than those listed in the allowed-values tag. The allowed-values are supported only for string data types. If allowed-values are not provided, all values are acceptable – including the strings which have length 0. The allowed values can be defined like:

Range

The range constraint restricts the value of an attribute to the user defined range, or the document gets rejected. Currently, range is supported only for int32, int64, double, decimal and datetime. If range is not provided, all values will be accepted. An example of range is given below:

This is how the current Constraints.conf file looks:

For now, it contains 4 attributes, namely “name”, “age”, “details” and “time”. This means that the document being inserted must contain all of these attributes.

About name, we have mentioned that its data-type is string and the default-value is ‘NY’. With that we have also restricted it to have no other value then ‘NY’, ‘CA’, ‘TX’.

For the age attribute, we defined its data-type as Int64 and the value must lie between ‘0’ and ‘100’.

The details attribute has a default-value, meaning if user does not provide details, it will simply add ‘NA’ as details and accept the document.

ClientApp Project

This project is a simple application for testing a use case of validating data with triggers. It tries to test the registered trigger after inserting different documents into the database. Some of them fulfill the imposed constraints and some do not. The documents fulfilling the constraints will get accepted for storage and the others will be rejected.

Customizing Applications for Data Validation with Triggers

You can also modify this application to fit your use case. The rules folder contains the different rules applied on a document attribute before inserting it in the database. You can add, update or skip the rule definitions to suit your data use case.

Conclusion

This blog was written to provide a simple triggers implementation which can be used to validate data in a .NET NoSQL Database before storage. The rules defined in the provided solution verify whether the document contains specified attribute(s) or not. The application is also capable of imposing data-type, range and value constraints. In short, we introduced a ‘partial schema’ in a schema-less database.

Much more can be done using this basic trigger validation project. You are free to modify as you like and it will be great if you can contribute to this project. ValidationThroughTriggers

Leave a Reply

Your email address will not be published. Required fields are marked *