Migration Practices

Guidelines for database migrations in the Fangate backend.

---

Stack

• Laravel migrations (in database/migrations/)
• MySQL or MariaDB
• Eloquent ORM for models

---

Running Migrations

# From backend root
cd Fangate-backend
php artisan migrate

# With seed data
php artisan migrate --seed

# Rollback
php artisan migrate:rollback

# Fresh (drop all, re-run)
php artisan migrate:fresh

---

Best Practices

1. Name Migrations Clearly

YYYY_MM_DD_HHMMSS_create_products_table.php
YYYY_MM_DD_HHMMSS_add_seo_enabled_to_products.php

2. Use Reversible Changes

public function up()
{
    Schema::table('products', function (Blueprint $table) {
        $table->boolean('seo_enabled')->default(false);
    });
}

public function down()
{
    Schema::table('products', function (Blueprint $table) {
        $table->dropColumn('seo_enabled');
    });
}

3. Avoid Data Loss

• Prefer nullable() for new columns when existing rows exist
• Use default() when safe
• For destructive changes, consider a two-phase migration

4. Index Frequently Queried Columns

• user_id on products, wallets, transactions
• link_hash on products (unique)
• email on users (unique)

5. Document Schema Changes

• Update this documentation when schema changes
• Note breaking changes in Changelog

---

Common Operations

Add Column

$table->boolean('seo_enabled')->default(false);

Add Foreign Key

$table->foreignId('user_id')->constrained()->onDelete('cascade');

Add Index

$table->index('link_hash');
$table->unique('link_hash');

Soft Deletes

$table->softDeletes();

---

Handoff Notes

• Migrations should be run before deployment
• Production: ensure backups before migrate
• Staging: test migrations before production
• Coordinate with team on schema changes that affect API responses