Target-specific

Forward-engineering scripts vary widely between target technologies, as each one has developed its own storage model, terminology, syntax, data types, indexing and partitioning, etc.For details, you should consult the applicable page 

 

Note: this capability is only available in the Professional, Workgroup, and Free Trial editions of Hackolade Studio.

 

 

Script generation parameters

With v8.2.3, we started to introduce parameters to allow you to adjust the DDL script generation according to your preferences.  This may be for styling purposes, or more importantly for data loading or performances reasons.  Additionally, it may allow you to document data models constraints that you do not want to have enforced by the database engine.

 

The configuration is available from Tools > Options > Forward-Engineering > Script Generation:

 

 

 

It is also available from a button at the bottom of the DDL script tab, and from a button at the bottom of the forward-engineering table selection dialog.

 

 

Script generation parameters are persisted in a JSON file script-generation-options.json stored in the C:\Users\Pascal\.hackolade\options\<target> folder.

 

Script generation parameters when using the CLI

When running the Command-Line Interface locally, it accesses the same configuration file as persisted by editing your preferences in the GUI application, i.e., the file script-generation-options.json stored in the C:\Users\Pascal\.hackolade\options\<target> folder.

 

When running the CLI on a server, you must copy the script-generation-options.json file and paste in the appropriate .hackolade\options\<target> folder of the CLI instance.  

 

If running the CLI in Docker, you must paste the script-generation-options.json file in the appropriate location, as described here.

 

 

Custom script hooks

The Custom script hooks feature allows you to inject custom content (such as statements or comments) at predefined points in the generated DDL script. Instead of manually editing the generated script after export, you can define custom content that is automatically inserted before or after specific CREATE operations.

 

This feature is currently available for the regular data model of:

- Oracle

- PostgreSQL

- Snowflake

 

ALTER comparison scripts of delta models do not support yet custom script hooks.

 

Hook points

You can insert custom content at 6 predefined positions in the generated script:

- Before CREATE SCHEMA

- After CREATE SCHEMA

- Before CREATE TABLE

- After CREATE TABLE

- Before CREATE VIEW

- After CREATE VIEW

 

These hook points define where your custom content is placed relative to the corresponding CREATE operation.

 

Customization levels

Custom script hooks can be defined at different levels. The level determines the scope of application.

 

Model level

Applies to all schemas, tables, and views within the model. Use this level to enforce global standards across the entire script.

 

Schema level

Defined on a schema (database). Applies to that schema, all tables and views inside that schema. Use this when you want consistent behavior within a specific schema.

 

Table / View level

Defined directly on a specific table or view. Applies only to that object. Use this when customization is object-specific.

 

Level priority and execution order

When hooks are defined at multiple customization levels, they are cumulative.

 

For the same hook point:

- Before hooks execute from the highest level to the most specific level.

- After hooks execute from the most specific level to the highest level.

 

This ensures a consistent and predictable ordering when combining model, schema, and object-level definitions.

 

When table constraints are configured to be generated as separate statements (see Script Generation Options), the After CREATE hook is inserted immediately after the CREATE statement itself. It does not include the subsequent ALTER statements, which are placed later in the script.

 

Note that "After CREATE SCHEMA" follows the same principle: it is executed immediately after the CREATE SCHEMA statement itself, not after all objects within that schema. If you need to insert content at the very end of the entire script, use the model-level Footer script instead.

 

The example screenshot illustrates a complete model where hooks are defined at all available levels. It shows both the priority between levels and the resulting execution order across schemas, tables, and views.

 

 

 

Using variables

Custom scripts can use predefined variables. These are resolved automatically during script generation. This allows you to write reusable scripts without hardcoding object names.

 

Supported variables:

- ${tableName} – current table name

- ${viewName} – current view name

- ${schemaName} – current schema, database, or equivalent container

 

The exact variable names can differ depending on the target (for example, schema vs database vs user). The list of supported variables for the selected target is displayed in the footer of the Custom script hooks dialog. Variables can be copied directly from the tooltip to avoid typing errors.

 

 

 

If a variable is used outside of its applicable scope (for example, ${tableName} at model level), it is not resolved and is replaced with an empty value in the generated script. Any unknown or invalid variable is also ignored and replaced with an empty value.

 

Example scenarios

 

Grant privileges automatically:

 

GRANT SELECT ON ${schemaName}.${tableName} TO analytics_role;

 

Add logging:

 

CALL log_object_creation('${tableName}');

 

Add comment:

 

COMMENT ON TABLE ${schemaName}.${tableName} IS 'Managed by Hackolade';

 

Important notes

- Custom scripts extend generated DDL. They do not replace CREATE statements.

- Injection happens at deterministic points in the final assembled script.

- The feature affects DDL script generation only. Other exports (JSON, YAML, ArchiMate, etc.) are not impacted.

- Delta model alter scripts are not yet supported.