Validation within the KCL Programming Language | by Peefy | Jan, 2023
Kusion Configuration Language (KCL) is an open-source constraint-based document and useful language. KCL improves the writing of numerous complicated configurations by means of mature programming language expertise and follow, and is dedicated to constructing higher modularity, scalability and stability round configuration, less complicated logic writing, quick automation and good ecological extensionality.
Set up KCL:
Every launch of KCL consists of varied OSes and architectures. These binary variations will be manually downloaded and put in from Github and add {install-location}/kclvm/bin
to the surroundings PATH.
export PATH=$PATH:{install-location}/kclvm/bin
Along with utilizing KCL code to generate configuration codecs akin to JSON/YAML, KCL additionally helps format validation of JSON/YAML knowledge. As a configuration language, KCL covers virtually all options of OpenAPI.
In KCL, a construction definition can be utilized to validate configuration knowledge. On the similar time, it helps user-defined constraint guidelines by means of the test block, and writes validation expressions within the schema to test and validate the attributes outlined by the schema. It is extremely clear and easy to test whether or not the enter JSON/YAML satisfies the corresponding schema construction definition and constraints.
Within the schema, we will use the test
key phrase to jot down the validation guidelines of each schema attribute. Every line within the test block corresponds to a conditional expression. When the situation is happy, the validation is profitable. The conditional expression will be adopted by , "test error message"
to point the message to be displayed when the test fails. Right here is an instance of a schema with constraint expressions.
import regexschema Pattern:
foo: str # Required, can't be None/Undefined, and the kind should be str
bar: int # Required, can't be None/Undefined, and the kind should be int
fooList: [int] # Required, can't be None/Undefined, and the kind should be int record
coloration: "Crimson" | "Yellow" | "Blue" # Required, literal union sort, and should be one in all "Crimson", "Yellow", "Blue".
id?: int # Non-obligatory, will be None/Undefined, the kind should be int
test:
0 <= bar < 100 # bar should be better than or equal to 0 and fewer than 100
0 < len(fooList) < 100 # fooList can't be None/Undefined, and the size should be better than 0 and fewer than 100
regex.match(foo, "^The.*Foo$") # common expression matching
bar in vary(100) # bar can solely vary from 1 to 99
bar in [2, 4, 6, 8] # bar can solely take 2, 4, 6, 8
bar % 2 == 0 # bar should be a a number of of two
all foo in fooList {
foo > 1
} # All components in fooList should be better than 1
any foo in fooList {
foo > 10
} # Not less than one component in fooList should be better than 10
abs(id) > 10 if id # test expression with if guard, when id shouldn't be empty, absolutely the worth of id should be better than 10
To sum up, the validation sorts supported in KCL schema are:
There’s a JSON format file knowledge.json
:
{
"identify": "Alice",
"age": "18",
"message": "That is Alice",
"knowledge": {
"id": "1",
"worth": "value1"
},
"labels": {
"key": "worth"
},
"hc": [1, 2, 3]
}
Construct a validated KCL file schema.ok
:
schema Consumer:
identify: str
age: int
message?: str
knowledge: Information
labels: {str:}
hc: [int]test:
age > 10
schema Information:
id: int
worth: str
Execute the next command:
$ kcl-vet knowledge.json schema.ok
Validate succuss!
Based mostly on this, KCL offers the corresponding Validation Tool to validate JSON/YAML knowledge immediately. As well as, based mostly on this functionality, we will construct a Okay-V validation visualization product.
The development of KCL validation capabilities will step by step give attention to the “static” facet, that’s, at compile time, mixed with the flexibility of formal validation, it may well immediately analyze whether or not the information meets the constraints, whether or not the constraints battle with one another, and so forth., and will be uncovered in real-time by means of the IDE.
We additionally anticipate that KCL fashions and constraints will be managed as a package deal (this package deal has solely KCL recordsdata). For instance, the Kubernetes fashions and constraints can be utilized out of the field. Customers can generate configurations or confirm present configurations, and might merely lengthen the fashions and constraints customers need by means of KCL inheritance.