<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

/**
 * Estado de publicación para los seis tipos de contenido que no lo tenían (MGR-023).
 *
 * **El hallazgo era del esquema, no del código.** De los siete tipos de contenido
 * versionado, solo `setups` tenía columna de estado; los otros seis se sirven **en cuanto se
 * crean**, a todos los entornos que resuelvan esa versión. No había borrador, ni «preparado
 * sin publicar», ni deprecación: se editaba en producción.
 *
 * Y eso choca con cómo se autoría de verdad: preparar la documentación de una versión de
 * producto lleva días y varias manos. La única forma de no publicar a medias era no crear la
 * versión hasta tenerlo todo, o crearla con un número más alto que ninguna instalación tenga
 * aún — un truco, no un mecanismo.
 *
 * ## Qué pasa con lo que ya está cargado
 *
 * **Todo pasa a `active`**, que es el defecto de la columna. Es la única opción que no rompe
 * a nadie: cualquier otra dejaría de servir contenido que hoy se sirve, y el cliente lo
 * notaría antes que nosotros. La pregunta la dejaba abierta el propio issue y esta es la
 * respuesta.
 *
 * ## Por qué `string` y no un enum
 *
 * Porque es lo que ya usa `setups`, y dos representaciones del mismo estado en la misma base
 * de datos es el problema que este cambio viene a quitar, no a duplicar.
 */
return new class extends Migration
{
    /**
     * Las seis tablas a las que les falta el estado.
     *
     * `setups` no está: ya lo tiene, y es de donde sale la semántica.
     */
    private const TABLAS = [
        'feature_versions',
        'tutorial_versions',
        'resource_versions',
        'scss_versions',
        'js_versions',
        'scss_cdn_bundles',
    ];

    public function up(): void
    {
        foreach (self::TABLAS as $tabla) {
            if (! Schema::hasTable($tabla) || Schema::hasColumn($tabla, 'status')) {
                continue;
            }

            Schema::table($tabla, function (Blueprint $table) use ($tabla) {
                $table->string('status', 20)->default('active')->after('version');

                // **Compuesto y en este orden.** La consulta que lo usa es la del
                // resolvedor —«las versiones servibles de este producto»—, o sea
                // `product_id` primero y `status` después. Un índice solo de `status` no
                // serviría: son tres valores y el motor lo ignoraría.
                $table->index(['product_id', 'status'], substr($tabla, 0, 20) . '_prod_status_idx');
            });
        }
    }

    public function down(): void
    {
        foreach (self::TABLAS as $tabla) {
            if (! Schema::hasTable($tabla) || ! Schema::hasColumn($tabla, 'status')) {
                continue;
            }

            Schema::table($tabla, function (Blueprint $table) use ($tabla) {
                $table->dropIndex(substr($tabla, 0, 20) . '_prod_status_idx');
                $table->dropColumn('status');
            });
        }
    }
};