Interface SqlLoggingOptions

Optional batch separator to emit after each statement (e.g., "GO" for SQL Server)

Optional default schema name to use for Flyway migrations for replacing schema names with the placeholder ${flyway:defaultSchema}

Used only when schemaPlaceholders is absent or empty.

Optional description to include as a comment at the start of the log

Escape ${...} inside SQL string literals so Flyway/Skyway does not read captured data (template text, prompt bodies) as a placeholder. Always on when formatAsMigration is true; set it to get the escaping without migration formatting.

Optional user ID to filter SQL logging - only log SQL executed by this user

Array of patterns to filter SQL statements. Supports both regex (RegExp objects) and simple wildcard patterns (strings). How these patterns are applied depends on filterType.

String patterns support:

• Simple wildcards: "AIPrompt", "spCreate*", "*Run"
• Regex strings: "/spCreate.*Run/i", "/^SELECT.*FROM/i"

RegExp examples:

• /spCreateAIPromptRun/i - Match stored procedure calls
• /^SELECT.*FROM.*vw.*Metadata/i - Match metadata view queries
• /INSERT INTO EntityFieldValue/i - Match specific inserts

Determines how filterPatterns are applied:

• 'exclude': If ANY pattern matches, the SQL is NOT logged (default)
• 'include': If ANY pattern matches, the SQL IS logged

Note: If filterPatterns is empty/undefined, all SQL is logged regardless of filterType.

Whether to format output as a flyway migration file with schema placeholders

Whether to log record change metadata wrapper SQL (default: false). When false, only core spCreate/spUpdate/spDelete calls are logged

Whether to pretty print SQL statements with proper formatting

Whether to retain log files that contain no SQL statements (default: false). When false, empty log files are automatically deleted on dispose

Schema-to-placeholder rules for migration formatting (#3618). When set, they replace the single defaultSchemaName -> ${flyway:defaultSchema} rewrite.

${flyway:defaultSchema} is the core schema in MJ's own repo, but in an Open App repo Skyway binds it to the app schema and ${mjSchema} to core. An Open App therefore supplies both:

schemaPlaceholders: [
  { schema: '__mj_BizAppsAccounting', placeholder: '${flyway:defaultSchema}' },
  { schema: '__mj', placeholder: '${mjSchema}' },
]
Copy

The rules run in one pass, so an emitted placeholder is never rewritten again. A schema name is rewritten only when a . follows it (optionally after a closing ]), which also keeps a short rule off the prefix of a longer schema name, and no word character, $, @ or # precedes it. Code and string data are treated alike: __mj. inside a quoted literal is rewritten; a bare name with no . after it is left alone.

Ignored unless formatAsMigration is true.

Optional friendly name for this logging session (for UI display)

Which types of statements to log: 'queries' (all), 'mutations' (only data changes), 'both' (default)

Optional rewrite of each logged text before the session reads it: the statement, its simple-SQL fallback, the description and the -- Parameters: line. It runs before the verbose prints, the filters, the Flyway escape, the schema-placeholder rewrite and the pretty-print, so text it removes never reaches the log file or the console, and SQL it adds that names a real schema ([__mj].Entity) is rewritten to that schema's placeholder like the rest of the statement.

It covers only this session's file and verbose prints, plus the provider's shared verbose Query to log: print. Other sessions and other output paths do not use it.

If it throws, the error is caught: the session writes the fixed line -- Statement not logged: TransformStatement failed in place of the statement and the SQL call goes on as normal.

When set, enables variable-count-based batch separation instead of emitting the batch separator after every statement. The logger tracks how many SQL variable declarations (DECLARE @...) have accumulated in the current batch. When the running count reaches this threshold, a batch separator is emitted before the next statement and the counter resets.

This prevents SQL Server's 10,000-variable-per-batch limit from being hit on large migration files while avoiding the verbosity of one GO per statement.

Requires batchSeparator to also be set. Recommended value: 200. Set to 0 or leave undefined to use the legacy per-statement behavior.

Whether to output verbose debug information to console (default: false)