Skip to content

Tilda JSON Syntax

Jump to bottom
Laurent Hasson edited this page Mar 15, 2024 · 11 revisions

Tilda uses JSON-based definition files to create models, including support for tables, views, datamarts, formulas etc...

Main file structure

The base construct for Tilda are Schemas. We typically segment our applications in multiple components with database-side schemas holding your data with tables and views described there. Such a file must abide to a convention:

  • The file must be named, for example, like _tilda.Organizations.json
  • The middle part “Organizations” will be the case-insensitive name of your Schema in the database A Tilda Definition file is a JSON data structure with the following top-level elements:
{
  "package":"com.capsico.organizations.data"
 ,"dynamic":true|false
 ,"dependencies": ["com/capsico/people/data/_tilda.People.json"
                  ,"com/capsico/codesmaster/data/_tilda.CodesMaster.json"
                  ]
 ,"documentation": {
     "description": [
         "This schema blah blah blah and "
        ,"more blah blah blah<BR>"
        ,"<B>Copyright (c) 2018, CapsicoHealth Inc., All rights reserved.</B>"
      ]
   }
 ,"conventions":{
   }
 ,"extraDDL":{
     "before":["_tilda.Organizations.postgres.procedures.sql"]
    ,"after":["_tilda.Organizations.postgres.postmigrate.sql"]
   }
 ,"objects":[
   ]
 ,"views": [
   ]
 ,"migrations":{
   }
}

The fields are:

  • package: the name of the package where the file is located.
  • dynamic: whether this is a dynamic schema or not. Dynamic schemas are not considered by drop scripts as they are expected to contain dynamic tables/views managed by an application.
  • dependencies: a list of other Tilda definition files, as java package paths, representing schemas that this schema is dependent on (for foreign keys and views)
  • documentation: multi-line HTML-based documentation for the schema
  • extraDDL: names of one or more custom SQL files to be run before and after the data definitions automatically generated by Tilda. This can be used to support more aggressive migration strategies, or simply to create artifacts such as stored procedures that Tilda does not handle. Each sql file must abide by the following naming convention:
    • _tilda.<schema_name>.<db_type>.<some_name>.sql
    • You can have multiple files for multiple databases although at this time, only Postgres is supported.

Overall, Schemas are containers of objects (e.g., Tables), and Views:

Clone this wiki locally