Data

Migrations

Netpress now uses one shared migration directory and one shared schema builder for SQL and MongoDB. The framework analyzes the migration files first, plans the targeted connections, and then runs only the connections those files actually reference.

Generated migrations can use the shared log helper for readable, colorful CLI output during migrate, rollback, and refresh flows.

Quick Example

// database/migrations/20260419_create_posts_table.js
import { log } from "@admicaa/netpress";

export async function up(database) {
  const schema = database.connection("mysql");

  await schema.createTable("posts", (table) => {
    table.primaryKey("id");
    table.foreignId("userId")
      .notNullable()
      .references("id")
      .inTable("users")
      .onDelete("cascade");
    table.string("title", 255).notNullable();
    table.string("slug", 255).notNullable().unique();
    table.text("body").notNullable();
    table.string("status", 20).notNullable().defaultTo("draft");
    table.datetime("publishedAt").nullable();
    table.timestamps(true, true);
    table.index("userId");
  });

  log.success("Migration completed: posts created.");
}

export async function down(database) {
  const schema = database.connection("mysql");
  await schema.dropTableIfExists("posts");
  log.success("Migration rolled back: posts dropped.");
}

If the migration should target the default configured connection, you can use database.createTable(...) directly instead of database.connection(...).

table.primaryKey("id") is the recommended default for shared migrations:

SQL connections map it to bigIncrements
MongoDB maps it to a native ObjectId
table.primaryKey("id", { mongo: "increments" }) switches MongoDB to numeric ids

Supported Schema Methods

Table Methods

createTable(name, callback)
alterTable(name, callback)
dropTableIfExists(name)
connection(name)

Column Methods

primaryKey(name = "id", options = {})
increments(name = "id")
id(name = "id")
string(name, length = 255)
text(name)
integer(name)
float(name)
decimal(name, precision = 8, scale = 2)
boolean(name)
datetime(name)
timestamp(name)
json(name)
foreignId(name)
timestamps(useTz = false, defaultToNow = false)

Column Modifiers

primary()
notNullable()
required()
nullable()
defaultTo(value)
unique(indexName?)
index(indexName?)
unsigned()
trim()
lowercase()
enum(values)
minLength(length)
maxLength(length)
references(column)
inTable(table)
onDelete(action)
onUpdate(action)

Table-Level Index Helpers

index(columns, indexName?)
unique(columns, indexName?)

Connection Planning

Migration execution works differently now:

Netpress discovers the migration files first
it analyzes which connections each file targets
it opens only the referenced connections
it tracks executed migrations per connection

This is why the current migrate commands do not need runtime --connection flags in the docs flow.

Commands

npm run artisan -- make:migration create_posts_table
npm run artisan -- migrate
npm run artisan -- migrate --seed
npm run artisan -- migrate:rollback --step=1
npm run artisan -- migrate:fresh --seed
npm run artisan -- migrate:refresh --seed
npm run artisan -- migrate:status

Legacy Compatibility

Older SQL migrations still work through the unified first argument in the common cases. The migration context preserves:

knex.schema.createTable(...)
knex(...)
knex.raw(...)
knex.fn.now()

That lets older migration files keep running while newer files use database.createTable(...) and database.connection(...).

MongoDB Behavior

The shared blueprint is translated into:

collection validators
indexes
in-memory schema metadata used by Mongo model boot

That means a Mongo-backed model can infer its shape from shared migrations without requiring handwritten static schema definitions.

Workflow

Create a migration with make:migration.
Keep the generated connection name if it matches your intended target, or change it to another configured connection.
Write up() and down() with the shared builder.
Run npm run artisan -- migrate.
Boot or test the app against the updated schema.