...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
const gridRowSchema = s.obj({
data: s.vec(s.con('')),
metadata: s.obj({
synapseRow: s.obj({
rowId: s.con(0),
versionNumber: s.con(0),
etag: s.con(''),
}),
rowValidation: s.con(0)
}),
});
const gridSchema = s.obj({
doc_version: s.con('0.1.0'),
columnNames: s.vec(s.con('')),
columnOrder: s.arr([s.con(0)]),
rows: s.arr([gridRowSchema]),
}); |
name | description |
|---|---|
| The semantic version of the document schema. This value will change anytime we change this schema. |
| This vector captures the name of the columns in their natural order (order they were added). Vectors are append-only (up to 256 values). Vectors allow LWW changes to each index. |
| This array defines the order that the columns should be displayed. Each value is an index into the |
| This is an |
| The row data |
| The row The object might be omitted if no additional information is included. This data should be treated as read-only for all replicas other than the hub. |
| The |
| The rowValidation value is a reference to a constant containing the JSON serialization of a: the ValidationResult object. Note: The ValidationResult is identical to results provided for Entity Validation. |
...
Agent MCP Service - This is a set of services that are available to an agent assisting with the grid. The two main services are:
Grid Query - SQL like query of the grid view.
Grid Update - SQL like updates from the agent. These updates are translated into patches (patch builder), that feed back to the hub like all other patches.
JSON Schema validation Worker - This worker listens to grid changes and applies validation state changes in the form of patches (via patch builder).
Exporter - Used to export data from the grid back to the original grid source.
Row Validation
Row validation occurs in the grid when JSON schema is bound to the grid session using one of the following techniques:
Schema Bound to Files of a View- For this case, if a JSON schema is bound to the files in a view, then this schema is detected when creating a grid using a query against such a view.
More options to be added….
Row validation is automatic. Anytime a cell is changed, a change event is sent to the validation worker via the Replica Change SQS queue (see communication diagram). The validation worker will re-validate the entire row and produce a ValidationResult. If the new result is different than the old, then worker will trigger the creation of a patch that will update the validation state of that row.
One cell’s validation result might be dependent on state of another cell within the same row. For example, consider the following JSON Schema where column “b” is required if column “a” has a value greater than 100:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "Conditional Requirement Schema",
"type": "object",
"properties": {
"a": {
"type": "integer",
"description": "An integer value."
},
"b": {
"type": "string",
"description": "A string value, required if 'a' > 100."
}
},
"if": {
"properties": {
"a": {
"minimum": 100
}
},
"required": [
"a"
]
},
"then": {
"required": [
"b"
]
}
}
|
Given this example schema, the following table shows the validation results for rows with various values:
a | b | ValidationResults |
|---|---|---|
200 | “aString” |
|
99 | “aString” |
|
99 | null |
|
101 | null |
|
89 | true |
|
true | “aString“ |
|
Create a Grid in Synapse
The following steps show how a client will connect to a Synapse grid:
...