SchemaTongs for MySQL

Overview

SchemaTongs is the starting point of the SchemaSmith workflow. It connects to a MySQL database and extracts metadata representing the current state of that database - tables, procedures, views, etc. This metadata becomes the raw material that feeds into the SchemaSmith toolchain for shaping and deploying your desired state across environments. We call this initial process of extracting schema definitions casting the database.

Simply point the application at each of your databases and everything within them will be extracted out to the folder of your choosing.

Where SchemaTongs Fits

SchemaTongs extracts your schema into metadata.
SchemaHammer provides powerful search and edit capabilities for your metadata.
SchemaQuench applies your schema and data metadata to your MySQL server.
DataTongs extracts your seed data into metadata

Quick Start Guide

1. Configure your appSettings.json

Point SchemaTongs at your source database. MySQL requires username and password authentication. Note that MySQL uses Source:Schema instead of Source:Database. All object types are extracted by default. Use ObjectList to limit extraction to specific objects:

{
  "Source": {
    "Server": "localhost",
    "Schema": "sakila",
    "User": "root",
    "Password": "your_password"
  },
  "Product": {
    "Path": "/opt/schemapackage",
    "Name": "Sakila"
  },
  "Template": {
    "Name": "Sakila"
  },
  "ShouldCast": {
    "Tables": true,
    "UserDefinedFunctions": true,
    "StoredProcedures": true,
    "TableTriggers": true,
    "Views": true,
    "Events": true,
    "ObjectList": ""
  }
}

2. Run SchemaTongs

Execute SchemaTongs from the command line and the casting process will begin.

> SchemaTongs

3. Shape your metadata

Move on to editing your metadata with SchemaHammer.

See the SchemaTongs Walkthrough to help you get started with the tool.

Tip

The same concepts for how to override appSettings.json for SchemaQuench apply to SchemaTongs. You can also use Command Line Options to specify the log file location or an alternate config file.

What is Exported

SchemaTongs extracts 6 object types from MySQL. Tables are exported as JSON definitions; all other objects are exported as SQL scripts. Events are a MySQL-specific object type for scheduled tasks.

Object Type	Directory	Format
Tables	`Tables/`	JSON (`table.json`)
Functions	`Functions/`	SQL (`name.sql`)
Stored Procedures	`Procedures/`	SQL (`name.sql`)
Triggers	`Triggers/`	SQL (`table.trigger.sql`)
Events	`Events/`	SQL (`name.sql`)
Views	`Views/`	SQL (`name.sql`)

All directories are relative to Product:Path/Templates/Template:Name/. MySQL does not use schema-qualified names in file paths since Source:Schema targets a single database.

Package Initialization

On the first cast to a new product path, SchemaTongs creates Product.json and Template.json with default values, along with JSON schema files in .json-schemas/ for editor validation. All script folders are created physically on disk.

On subsequent casts, Product.json and Template.json are never overwritten; only the extracted object scripts and table JSON files are refreshed. New templates are added to the product's TemplateOrder automatically.

After your first cast, review and customize Product.json and Template.json, particularly ValidationScript, SchemaIdentificationScript, and VersionStampScript, to match your deployment needs.

Extraction Details

ObjectList Filtering

By default, SchemaTongs extracts all objects from the database. Set ShouldCast:ObjectList to a comma or semicolon-separated list of object names to limit extraction to specific objects only.

Matching is case-insensitive and supports both bare names and schema-qualified names:

"ObjectList": "film" - matches the film table
"ObjectList": "sakila.film" - matches only film in the sakila schema
"ObjectList": "film,film_in_stock,actor_info" - matches multiple objects

ObjectList uses exact string matching only, no wildcards or regular expressions. The filter applies to all object types (tables, views, functions, etc.).

Excluded Objects

The following objects are automatically excluded from extraction:

Exclusion	Reason
`SchemaSmith_` prefix	Helper infrastructure installed by SchemaTongs itself. All objects with names starting with `SchemaSmith_` are filtered from every object type.

MySQL system schemas (mysql, information_schema, performance_schema, sys) are not extracted because SchemaTongs only queries the single schema specified in Source:Schema.

Helper Infrastructure

Before extraction, SchemaTongs installs helper objects with a SchemaSmith_ prefix in the target database. Unlike SQL Server and PostgreSQL, MySQL does not use a separate schema for infrastructure objects. They include:

Functions: SchemaSmith_QuoteIdentifier, SchemaSmith_StripBacktickWrapping, SchemaSmith_SafeBacktickWrap, SchemaSmith_NormalizeIndexColumns - identifier quoting and string manipulation helpers.
Procedures: SchemaSmith_GenerateTableJSON - extracts complete table definitions as JSON. Plus table quench procedures (SchemaSmith_TableQuench, SchemaSmith_IndexOnlyQuench, SchemaSmith_ForeignKeyQuench, etc.) used by SchemaQuench at deployment time.
Tables: SchemaSmith_CompletedMigrationScripts - tracks which migration scripts have been executed. SchemaSmith_ProductOwnership - maps tables and indexes to their owning product. SchemaSmith_StatusMessages - progress and status reporting during operations.

These objects are excluded from extraction output automatically. The SkipKindlingForge command-line argument can skip this installation step if the helpers are already present.

Re-extraction Preservation

When SchemaTongs re-extracts into an existing schema package, it preserves user-configured properties that were added after the initial extraction. This means you can safely re-run SchemaTongs without losing your customizations.

Preserved on table JSON files:

Data delivery properties: ContentFile, MergeType, MatchColumns, MergeFilter, MergeDisableTriggers
OldName (for tracking table renames)
ShouldApplyExpression (conditional deployment logic)
All custom properties on tables, columns, indexes, foreign keys, check constraints, and full-text indexes

Components are matched by name (case-insensitive, with backtick stripping) or by OldName for renamed objects. Schema structure is always refreshed from the database; only user-defined metadata is preserved.

Script Formatting

Functions, stored procedures, triggers, and events are wrapped with DELIMITER // blocks. Each script begins with a DROP ... IF EXISTS statement followed by the CREATE definition, then resets the delimiter with DELIMITER ;.

Views use DROP VIEW IF EXISTS followed by CREATE VIEW without DELIMITER wrapping.

All line endings are normalized to \r\n (Windows CRLF) regardless of the source database platform.

ShouldCast Flags Reference

Flag	Default	Description
`Tables`	`true`	Extract table definitions as JSON files. Includes columns, indexes, foreign keys, check constraints, and full-text indexes.
`UserDefinedFunctions`	`true`	Extract user-defined functions.
`StoredProcedures`	`true`	Extract stored procedure definitions.
`TableTriggers`	`true`	Extract DML triggers on tables (BEFORE/AFTER INSERT, UPDATE, DELETE).
`Views`	`true`	Extract view definitions.
`Events`	`true`	Extract MySQL event scheduler definitions (scheduled tasks). This is a MySQL-specific object type.
`ObjectList`	`""`	Comma or semicolon-separated list of object names to extract. Leave empty to extract all objects. See Extraction Details.

Additional Resources

SchemaTongs Walkthrough - A step-by-step guide for casting the sample product. How-to Product Demos - Sample databases converted to the SchemaSmith metadata format. Examples Configuration Settings Reference - Explore the configuration options available in appSettings.json. Reference Product Definition Guide - Structure your metadata into products. Reference SchemaHammer - An IDE for editing your metadata. Related Run SchemaTongs with Ask Forge - Execute schema extraction through the AI assistant. AI Assistant

SchemaTongs - MySQL (Enterprise)