Tilda JSON Syntax: Object Cloning

<-- Object Syntax

Cloning

Cloning allows you to create "copies" of a table following the same model, i.e., columns, foreign keys, identities and so on. This can become useful in a variety of cases:

• poor man's version of partitioning
• creating copies of data in a versioned separate table, for example, like a "dev" vs "published" version of some data
• defining many tables that are structurally the same

Let's look at that last case in the context of a data warehouse and defining codeset tables (for lookups). One data warehouse design pattern is to create a single table with all codes jammed into it along with a type. For example:

pk	type	code	description
-1	N/A	N/A	Not Available
1	SEX	M	Male
2	SEX	F	Female
3	SEX	O	Other
4	MARITAL	M	Married
5	MARITAL	S	Single
6	MARITAL	D	Divorced
7	MARITAL	W	Widowed
...

This approach has one main inconvenient in that another table may mistakenly have a foreign key that is technically correct (i.e., points to the "CODES" table), but is semantically incorrect (e.g., a marital status field points to a sex value). With Tilda, we always encourage proper typing and constraint definitions at the model level, even if the model is deployed eventually to a constraint-less environment (e.g., BigQuery where foreign keys do not exist, which is common for many peta-scale cloud data warehouses)

Another approach is to model your types consistently and separate all code types into their own tables. You will then have to create many such tables, and over time, maintaining and keeping the design consistent becomes complicated. With cloning, this becomes simple, including managing consistent and contextual documentation.

   ,{ "name":"CodeMaritalStatus"
     ,"referenceUrl":"https://www.hl7.org/fhir/valueset-marital-status.html"
     ,"tag":"Marital Status"
     ,"description":"Codeset data for ${TAG}: ${REFERENCE_URL}."
     ,"cloneAs":[
         { "name":"CodeLanguage"                 , "fullName":true, "description":"?{}", "referenceUrl":"http://www.hl7.org/fhir/valueset-languages.html"                            , "tag":"Language" }
        ,{ "name":"CodeSpecialty"                , "fullName":true, "description":"?{}", "referenceUrl":"https://build.fhir.org/valueset-c80-practice-codes.html"                    , "tag":"specialty Code" }
        ,{ "name":"CodeDegreeLicenseCertificate" , "fullName":true, "description":"?{}", "referenceUrl":"https://terminology.hl7.org/4.0.0/ValueSet-v2-0360.html"                    , "tag":"Degree/License/Certificate" }
       ]
     ,"columns":[
         { "name":"code"      , "type":"STRING", "nullable":false, "size":  40, "description":"The code for ${TAG} as per ${REFERENCE_URL}." }
        ,{ "name":"system"    , "type":"STRING", "nullable":false, "size":1024, "description":"The system for this code, typically a URI."       }
        ,{ "name":"display"   , "type":"STRING", "nullable":false, "size": 256, "description":"The display value for this code." }
        ,{ "name":"definition", "type":"STRING", "nullable":true , "size":2048, "description":"The definition/description for this code." }
       ]
     ,"primary": { "autogen": true }
     ,"indices":[
          { "name":"Code"         , "columns":["code","system"]                             , "db": true }
         ,{ "name":"System"       , "columns":["system"], "orderBy":["code"]                , "db": true }
       ]
    }

In this use case, Tilda will create 4 tables (CodeMaritalStatus, CodeLanguage, CodeSpecialty and CodeDegreeLicenseCertificate) that will look identical except for the generated documentation that will be properly contextualized.

The attribute for a cloning definition are:

• name: the name for the cloned table.
• fullName: by default, false. If true, the 'name' specified is used as-is. If false, the 'name' specified is appended to the name of the main object, i.e., if a main object is called "Organization" and a clone is defined as "xxx", the new cloned object will be called "Organizations_xxx".
• description: a mandatory description for the cloned object. The placer "?{}" can be used to copy the description of the main object, so that if the main object's description is "blah blah" and the clone defined "?{} - And re-blah", then the cloned object's description will be "blah blah - And re-blah". This is useful to reuse base descriptions, yet customize the final description that is relevant to the cloned object.
• referenceUrl: optional, overrides the 'referenceUrl' value from the parent object.
• tag: optional, overrides the 'tag' value from the parent object.

🎈 NOTE: The key customization afforded to cloned tables are related to documentation. As such, the combination of object and column descriptions customized via 'referenceUrl' and 'tag' is where the power lies.