Blueprint

What's in this build

Blueprint is the suite's fifth tool. Like the others it authenticates through DBMojo Core and installs from Core's Tools page; it appears on the Launcher once it's installed and enabled for you.

Today Blueprint covers import, the ER canvas and editing, DDL generation, a model-versus-database diff, and filing that diff as a Core deployment request. Those three dialects are the ones it can introspect and generate DDL for.

Importing a schema

Click Import from connection, choose one of the Shared Data Connections you have access to, tick the schemas you want, optionally give the model a name (it defaults to the connection's name), and click Import. Blueprint asks Core for the connection's credentials at that moment, reads the catalog, and builds a model of the tables, columns, primary keys, foreign keys, and indexes it finds.

• Credentials are never stored. They are resolved from Core on every request that needs them — import, compare, and request — and used only for that call.
• A model is a snapshot. It's a JSON document saved in Blueprint's own database. Changing the live database later doesn't change the model; use Compare with database to see the difference.
• The model remembers which connection it came from, and compare/request default to it. A model can only be compared with a connection of the same dialect.
• A connection that uses TLS with a self-signed certificate is honoured the same way Detanami honours it — the connection's TLS trust setting decides whether the certificate is verified.
• Your models are listed in the sidebar. Click one to open it, or its × to delete it (see below). Import from file… under the button creates a model from a file instead — see Exporting & importing models.

The ER canvas

The imported model is drawn as an entity-relationship diagram. Each table is a card listing its columns with their types; PK and FK badges mark key columns, and a bullet marks a column that is not nullable. Relationships are lines between the card columns they connect, labelled with the constraint's name. The toolbar above the canvas has:

• + Table — add a new, empty table.
• Auto-layout — arrange the tables automatically so related tables sit together.
• Fit — zoom to show the whole model. A zoom control and a minimap sit in the corners, and you can drag tables wherever you like.

Reading the lines. Every relationship is drawn as an arrow from the child table (the one holding the foreign key) to the parent table it references, with the row count at each end: 0..* on the child end means a parent can have many children, 0..1 means at most one (the foreign key columns are the child's primary or a unique key, so the link is one-to-one); on the parent end, 1 means the foreign key columns are NOT NULL, so every child has a parent, and 0..1 means a child may have none. Blueprint derives these from your model — change a column's nullability or add a unique key and the line follows. A grey line is fine, an amber one has a warning, and a red one has an error.

A Legend panel on the canvas decodes all of this (and the PK/FK badges and the not-null bullet). It is collapsible and remembers whether you left it open.

A small badge on a table's header (⚠ for warnings, ✕ for errors, with a count) marks tables that have a problem — see Model checks.

The model's name in the title bar is editable in place: click the pencil or double-click the name, press Enter to save or Escape to cancel. Renames are validated and audited. The Delete button (and the × in the sidebar) asks for confirmation first: the dialog counts the tables and relationships that will go, says that deleting never changes a database or touches requests already filed in Core, and warns if requests for this model are still open in Core — they keep their SQL and can still be approved.

Table positions are saved as part of the model. Edits autosave a moment after you make them; the title bar shows Saving… then Saved beside the table and relationship counts.

Editing tables, columns & relationships

Click a table to open its inspector on the right. Click a relationship line to inspect that instead.

Tables and columns

• Rename a table and give it a comment. Names are checked as you commit them, and a conflict (a duplicate table or column name, for instance) is shown in the inspector rather than applied.
• For each column: rename it, set its type (a suggestion list offers the common types for the model's dialect, but any type is accepted), toggle NULL (allows null — a primary-key column can't) and AI (auto-increment), and set or clear a default.
• + Add column appends a column; the × beside a column deletes it. Delete table removes the table and its relationships from the model, after a confirmation.

Primary keys, indexes & unique keys

• The Primary key list is ordered and can hold several columns (a composite key). Add a column from the “+ add column…” drop-down, reorder with the arrows, or remove one with ×.
• Indexes & unique keys lists each one with its name, an Index / Unique switch, and its own ordered column list — multi-column indexes included, an index needs at least one column. + Index and + Unique key add new ones; × deletes one. Those discovered on import appear here too.

Relationships

To add a foreign key, drag from a column's right-hand dot to a column on another table. Select the resulting line to rename the constraint, edit the column pairs (child column → parent column; add more pairs for a composite key), choose its ON DELETE and ON UPDATE actions (NO ACTION, RESTRICT, CASCADE, SET NULL, or SET DEFAULT), or delete it. Adding a relationship that duplicates an existing one is refused.

The Add relationship dialog

If you would rather not drag, click + Relationship in the canvas toolbar, + Add relationship… in a table's inspector, or the arrow beside a column. Pick the child table (it holds the foreign key) and the parent table (it is referenced). Blueprint proposes the column pairing from the parent's key — it looks for a child column named after the parent and its key, such as brewery_id for breweries.id — and a constraint name, and you can edit the pairs, the name, and the ON DELETE and ON UPDATE actions.

Cardinality, and reversing a relationship

Selecting a relationship explains its cardinality in plain words at the top of the inspector (“Every order row refers to exactly one customer row…”) and suggests what to change to make it one-to-one or mandatory. ⇄ Reverse direction swaps child and parent — the foreign key moves to the other table — keeping the column pairs, any custom name, and any dismissed warnings.

Model checks

Blueprint checks the model as you edit it. The badge in the title bar shows the count — ✕ errors, ⚠ warnings, or ✓ No issues — and clicking it opens Model checks, listing every problem with the table or relationship it concerns. Click a problem to select that table or relationship on the canvas. Tables and relationships that have problems also show them in the inspector and as a badge on the canvas.

Dismissing warnings. A warning has Dismiss (hide it for that table or relationship) and Dismiss all like this (hide that kind of warning everywhere in the model). Dismissed warnings are kept at the bottom of the dialog with a Restore button, and they're saved with the model.

Exporting & importing models

The Export menu in the title bar writes the open model to a file in your browser — nothing is sent anywhere and no database is touched.

Importing a model file

Import from file… in the sidebar takes a model file written by Export → Model file (.json). Choose it or drop it on the dialog (it must be a JSON file under 10 MB). Blueprint validates it in the browser first and shows what it found — the number of tables and relationships, the dialect, and what the model checks say — or lists why the file can't be imported. The server then checks it again and rebuilds the model from known fields only before storing anything, so a hand-edited or foreign file can't smuggle in anything else.

The file becomes a new model with its own name (distinct from your existing ones — you can change it before importing); nothing existing is changed. The import is audited.

Generating DDL

The DDL button in the title bar (or Export → SQL script) shows the full CREATE script for the whole model, in the model's own dialect — MySQL, PostgreSQL, or SQL Server — including keys, indexes, and foreign keys. Copy puts it on the clipboard and Download .sql saves it as a file. It is generated, not executed.

Comparing with the database

Compare with database reads the live schema again (through the connection you choose) and works out the changes that would make the database match the model. It is a read-only operation.

1. Choose a Connection. Only connections of the model's dialect are offered.
2. Optionally tick Drop tables not in the model. By default the comparison is limited to the tables the model contains, so a partial model never proposes dropping the rest of the database.
3. Click Compare.

The result is a list of changes — creating or dropping tables, adding, altering, or dropping columns (type, nullability, auto-increment, default), and adding or dropping primary keys, indexes, and foreign keys — with ⚠ marking anything destructive that can lose data. Two tabs show the SQL:

If the database already matches, Blueprint says so and there is nothing to do. Both scripts can be copied or downloaded. Any model checks are shown above the change list.

Requesting a deployment

Below the scripts, add an optional note for the approver (“Why is this change needed?”) and click Request deployment. The button is disabled while the model has errors. If the plan contains destructive changes you must first tick This includes destructive changes that can lose data.

• Blueprint recomputes the SQL on the server when you request, rather than trusting what the browser shows, and files it in Core as a ddl request against that connection — with the rollback script and a list of the changes attached.
• The request lands in Core's Deployments queue as pending_approval. An approver sees the exact SQL, your note, and a comment thread, and approves or rejects it.
• Once approved, the request can be run from Detanami; the dialog links straight there. Detanami re-checks that the person running it has access to the connection and reports the result back to Core.
• A snapshot of the model is saved with each request, and the compare dialog lists Requests for this model — the request number, its current status read from Core, how many changes it holds, and when it was filed.

You can only file a request if the connection is one Core lets you target for deployments — see who can target vs. who can execute.

Links to the other tools

Blueprint finds the other tools' addresses from Core, and only links to tools that are installed and enabled for you.

Walkthrough: from a schema to an approved change

1. Make sure Blueprint is installed in Core and enabled for you, and that you can see a Shared Data Connection for a MySQL, PostgreSQL, or SQL Server database.
2. Open Blueprint and click Import from connection. Pick the connection and import — the tables and relationships appear on the canvas.
3. Click Auto-layout and Fit to read the diagram. Select a table and add a column, say a created_at timestamp, or drag a new foreign key between two tables.
4. Click DDL to review the model's full CREATE script if you want a clean copy of it.
5. Click Compare with database, choose the connection, and click Compare. Read the change list — here, one ALTER TABLE ... ADD COLUMN — and check the Rollback script tab.
6. Add a note for the approver and click Request deployment.
7. An admin opens Deployments in Core, reads the SQL, and approves it.
8. Open the request in Detanami (the dialog's link, or Run in Detanami) and execute it. Compare again in Blueprint: the database now matches the model.

Access & audit

• Sign-in and access come from Core like every tool; Blueprint has no separate login. You can only import from connections you've been granted.
• Models are private to their owner. Another user, including another admin, doesn't see them in Blueprint. Each deployment request keeps a saved version of the model, and deleting a model removes those saved versions and its request history in Blueprint (the requests in Core stay).
• Audited: importing, creating, renaming, updating, and deleting a model, running a compare, and filing a deployment request are all written to Core's central audit log under the blueprint tool. Filing a request is recorded at the highest audit level.
• Because Blueprint only introspects, the database account behind the connection needs read access to the catalog, not the rights to change anything — the changes themselves run in Detanami under its own access check.