We need to versionate json-schemas, so we can handle updates without breaking existing data.
Some of the points to be taken in account:
use a semantic versioning for the schemas. The minor version updates does no imply a new schema file, but major updates should require separate schema.
the resource should provide a @version identifier (otherwise we consider it as the last available version)
a migration mapping should be provided, so we can handle search through different schemas:
ver 1.0.0
{
"ctid": "xyz",
"descr": "abc"
}
ver 1.1.0
{
"ctid": "xyz",
"descrElements": {
"descr": "abc",
"shortDescr": "a"
}
}
Locator "dispatch" for query:
v 1.0.0: "descr" => /descr
v 1.1.0: "descr" => /descrElements/descr
So if someone searches for descr, there could be sql like:
where
-- descr seach "dispatch"
(
(schema_version = "1.0.0" and "/descr" = "abc")
OR
(schema_version = "1.1.0" and "/descrElements/descr" = "abc)
)
So for any searchable field, each schema version must maintain a "dispatch" locator for each searchable field. In this way, each schema is "responsible" for it's own query elements, and future schema don't need to know anything about that responsibility..
for a jsonb 'contains' query we should find the current 'path' query, and create a list of different versions for the same 'path', ORing them together as describe above
the JsonSchema class should handle this transparently.
We need to versionate json-schemas, so we can handle updates without breaking existing data. Some of the points to be taken in account:
@version
identifier (otherwise we consider it as the last available version)