You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All the VALVE implementations so far output to a message table, which identifies the table/row/column then specifies the message information. This is a flexible approach, but this requires the original table to have a primary key or row ID, and it can be difficult/annoying/expensive to combine the value and message when trying to render a table of highlighted cells.
I'd like to try another approach that keeps the message data in the table. Given a column such as 'weight' with datatype INT, we will have a second column 'weight_meta' with type TEXT. The 'weight_meta' column will store JSON that includes the message (when appropriate). For the first version, I would be happy with this:
weight
weight_meta
100
NULL
NULL
{"value":"99g","message":"Must be an integer"}
Eventually I would like to support multiple messages with more information, something like this:
{
"value": "99g",
"messages": [{
"rule": "datatype:integer",
"level": "error",
"message": "Must be a positive integer"
}]
}
What should the SQL for an in() condition look like for this approach?
The text was updated successfully, but these errors were encountered:
All the VALVE implementations so far output to a message table, which identifies the table/row/column then specifies the message information. This is a flexible approach, but this requires the original table to have a primary key or row ID, and it can be difficult/annoying/expensive to combine the value and message when trying to render a table of highlighted cells.
I'd like to try another approach that keeps the message data in the table. Given a column such as 'weight' with datatype INT, we will have a second column 'weight_meta' with type TEXT. The 'weight_meta' column will store JSON that includes the message (when appropriate). For the first version, I would be happy with this:
Eventually I would like to support multiple messages with more information, something like this:
What should the SQL for an
in()
condition look like for this approach?The text was updated successfully, but these errors were encountered: