Details
-
New Feature
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
Description
Currently JSON_SCHEMA_VALID and XMLISVALID take a complete schema as a second, string, argument.
Schemas are often quite large and putting the whole schema into a string into XMLISVALID into CHECK constraint would produce totally unreadable SHOW CREATE TABLE output.
Also, it needs to be repeated verbatim every time a validation is needed, which is error-prone.
Oracle solves it using a schema registry. First one registers a schema with, for example,
DBMS_XMLSCHEMA.registerSchema(schemaurl => 'my_schema.xsd', |
schemadoc => l_schema, -- this is a CLOB variable with a schema body |
local => TRUE, |
gentypes => FALSE, |
gentables => FALSE, |
enablehierarchy => DBMS_XMLSCHEMA.enable_hierarchy_none);
|
and then 'my_schema.xsd' can be used as a second argument for XMLISVALID().
We could have a table, say, mysql.xml_schema that would record such an url-to-schema mapping.
Issues to consider:
- privileges: who can register schemas, who can delete schemas, who can see what schemas
- can one use urls in CHECK constraints? it's kind of the whole point, but on the other hand, one can drop or modify the schema, making a data table with a CHECK constraint inconsistent. May be every row should have a version? At least we'll be able to detect if the schema changes. Or, may be, make it system versioned, then even if the schema was changed, the check constraint could use old version of the schema from the time when a table was created. And e.g. REPAIR will move to the latest version of the schema.
- should json schemas be in a separate table or in the same one with a column, like type ENUM('XML','JSON'). privileges and versioning applies to both, this suggests that one table makes sense