mariadb-corporation MSM — Developing the Next Version
After a release, prepare_release has already bumped the development version and
you continue editing development/<schema>_next.sql toward the next release.
This skill covers iterating on that script and the SOURCE breakout mechanism
for keeping it maintainable. See mariadb-schema-management for the section
model. Assume MariaDB 11.8.
Iterating on _next.sql
Make changes in the same sections you authored initially, using
msm.set_section_sql_content / msm.get_sql_content_from_section:
- New/changed tables and data → section 140.
- New/changed views, routines, triggers, events → section 150 (idempotent:
CREATE OR REPLACE/DROP IF EXISTS). - Grants/roles → section 170.
The development file always describes the full, current schema (not a diff) —
it is the source for the next version snapshot. The per-release migration from
the previous version is written separately when you prepare the release (see
mariadb-schema-management-release, sections 240/250/270).
Keep the development version in section 910 current with
msm.set_development_version as the target version firms up.
SOURCE breakout files (keeping the script maintainable)
When a section grows large, move its body into one or more files under
development/sections/ and reference them from _next.sql with a SOURCE
statement. MSM inlines this content when it snapshots the version during
prepare_release, so SOURCE is purely a development-time organizing tool —
released version and deployment scripts are always fully inlined.
Syntax
SOURCE '<relative-or-absolute-path>'[<start>:<end>]; -- optional comment
- The
[start:end]slice is required and is a character-offset slice of the referenced file's content (Python-style):[53:]— drop the first 53 characters (e.g. a one-line copyright header).[663:-115]— drop a 663-char header and the last 115 chars (footer).[:200]— keep only the first 200 characters.
- Relative paths resolve against the development/ folder (where
_next.sqllives), so use'./sections/...'. - The leading indentation of the
SOURCEline is applied to every inlined line.
Why the slice offsets
Each breakout file is a standalone, valid SQL file with its own copyright
header (and optionally a footer). The slice strips that header/footer so only the
object definitions are inlined into _next.sql. Pick the offset to match your
header length (count the characters up to the first real statement).
Example
development/<schema>_next.sql, section 140 body:
SOURCE './sections/140-10_tables.sql'[663:-115]; -- Ignore header and footer
SOURCE './sections/140-30_inserts.sql'[53:]; -- Remove copyright header
section 150 body:
SOURCE './sections/150-10_views.sql'[53:];
SOURCE './sections/150-20_procedures_functions.sql'[53:];
SOURCE './sections/150-30_triggers.sql'[53:];
File naming convention
Name breakout files <section-id>-<NN>_<topic>.sql so they sort in load order
and map back to their section, e.g. 140-10_tables.sql,
140-30_inserts.sql, 150-20_procedures_functions.sql, 170_roles.sql.
Rules
- Respect the section's placement/delimiter rule even in breakout files: content
destined for 140/170 must be plain
;-terminated (it lands in a stored-procedure body); content for 150 usesDELIMITER %%for routine bodies. - Keep the
SOURCElines inside the correct MSM section of_next.sql; edit that section body viamsm.set_section_sql_contentso the banners stay intact. - After editing breakout files, a
prepare_releasewill inline them; verify the generated version snapshot looks complete.
Next
When the development version is feature-complete, prepare a release:
mariadb-schema-management-release.
See Also
mariadb-schema-management— lifecycle overview and full section model.mariadb-schema-management-create— the initial project + first authoring.mariadb-schema-management-release— snapshot the version and write the migration.mariadb-alter-table,mariadb-create-view,mariadb-create-procedure— the DDL you edit here.