Similar to how column-defaults allows us to define bulk column-level annotations, table-defaults would allow us to define annotations for multiple tables on the schema or catalog.
This came up before as part of #982, but I decided to create a separate issue since it would be useful for other use cases as well. For example, this would allow us to change the default sort order to be based on RCT.
This annotation must be more complicated than column-defaults and have a mix-and-match logic (if the rules make sense, we can update column-defaults later as well). Instead of just having simple by_name property, we will introduce a selectors property that matches the definitions.
{
"tag:isrd.isi.edu,2023:table-defaults": [
{
"selectors": [
{
"schema_pattern": "",
"schema_names": "" | [],
"table_pattern": "",
"table_names": "" | [],
},
// ... other selectors
],
"default": {
// annotations go here
}
}
// ... other defaults
]
}
The following is how we will apply the annotations in each "default" object to the current table:
Can we match multiple default? In chaise-config, multiple can apply, and the order matters. Properties in the last matching rule will take precedence.
The selector object can have the following properties:
schema_pattern: A regular expression string.
schema_names: A string or array of strings.
table_pattern: A regular expression string.
table_names: A string or array of strings.
The following is how we match each object of the table-defaults array (need to come up with a better way to explain this):
Disjunction (or) between selectors.
Conjunction (and) of,
Disjunction of schema_pattern and schema_names.
Disjunction of table_pattern and table_names.
For the current case to work, we must merge the source-definitions of table-defaults with the local annotation on the table. In contrast, in column-defaults, local annotations of a column would simply replace the column-defaults ones. Requires more thought. I need to write down the rules, and then we need to discuss and finalize them. Because of this, we cannot allow all the annotation keys in this new annotation and have to explicitly explain which annotations and how they are supported.
Similar to how
column-defaultsallows us to define bulk column-level annotations,table-defaultswould allow us to define annotations for multiple tables on the schema or catalog.This came up before as part of #982, but I decided to create a separate issue since it would be useful for other use cases as well. For example, this would allow us to change the default sort order to be based on
RCT.This annotation must be more complicated than
column-defaultsand have a mix-and-match logic (if the rules make sense, we can updatecolumn-defaultslater as well). Instead of just having simpleby_nameproperty, we will introduce aselectorsproperty that matches the definitions.The following is how we will apply the annotations in each "default" object to the current table:
default? In chaise-config, multiple can apply, and the order matters. Properties in the last matching rule will take precedence.selector objectcan have the following properties:schema_pattern: A regular expression string.schema_names: A string or array of strings.table_pattern: A regular expression string.table_names: A string or array of strings.table-defaultsarray (need to come up with a better way to explain this):schema_patternandschema_names.table_patternandtable_names.For the current case to work, we must merge the source-definitions of
table-defaultswith the local annotation on the table. In contrast, incolumn-defaults, local annotations of a column would simply replace thecolumn-defaultsones. Requires more thought. I need to write down the rules, and then we need to discuss and finalize them. Because of this, we cannot allow all the annotation keys in this new annotation and have to explicitly explain which annotations and how they are supported.