Laravel 13.36 completa los builders de validación

Las reglas en texto acaban siendo difíciles de mantener

Las reglas de validación escritas como cadenas funcionan, pero se vuelven incómodas cuando acumulan parámetros, campos relacionados y excepciones. Un error de coma o de orden puede cambiar el significado de una regla sin que el editor ayude demasiado. Laravel 13.36 amplía los builders de Rule:: para cubrir las reglas que seguían dependiendo solo de sintaxis textual.

El resultado no es una validación distinta, sino una forma más explícita de declarar la misma intención. Gano autocompletado, métodos encadenables y menos concatenación de cadenas en Form Requests que ya tienen bastante lógica. También resulta más fácil revisar una regla cuando sus condiciones están expresadas como llamadas PHP. (laravel.com)

use Illuminate\Validation\Rule;
 
$request->validate([
    'website' => ['nullable', Rule::url()->protocols(['https'])],
    'device_id' => [Rule::uuid()->version(4)],
    'tags.*' => [Rule::distinct()->ignoreCase()],
    'phone' => [Rule::requiredWithout('email')],
]);

No hace falta convertir todas las validaciones existentes de golpe. Yo empezaría por reglas condicionales, listas de valores o validaciones que ahora mismo se construyen con interpolación. Son los casos donde una API fluida reduce más la ambigüedad y hace que los cambios posteriores sean menos frágiles.

Consultas analíticas sin dejar el modo OLAP activado

La otra novedad práctica está en conexiones MySQL que trabajan sobre Vitess, como PlanetScale. Laravel incorpora olap() en la conexión para ejecutar una consulta analítica dentro de un callback. Durante ese bloque establece el workload OLAP en las conexiones de lectura y escritura, y al terminar vuelve a OLTP incluso si la consulta lanza una excepción. (laravel.com)

use Illuminate\Support\Facades\DB;
 
$totals = DB::connection('mysql')->olap(
    fn ($connection) => $connection->table('orders')
        ->selectRaw('customer_id, sum(total) as total')
        ->groupBy('customer_id')
        ->get()
);

Esto elimina la necesidad de gestionar manualmente sentencias set workload y su limpieza posterior. Además, la documentación indica que en una conexión MySQL que no usa Vitess el callback se ejecuta sin modificar el workload. Eso permite mantener el mismo código entre desarrollo local y producción, siempre que la consulta sea válida en ambos entornos. (laravel.com)

Workers que no arrastran una conexión sticky

Los workers de cola viven durante mucho tiempo, y eso cambia el contexto de las conexiones de base de datos. Si una conexión de lectura y escritura usa sticky, una escritura puede hacer que las lecturas posteriores permanezcan en la conexión de escritura. En un worker, ese estado puede sobrevivir al job que lo provocó y afectar a los siguientes trabajos procesados por el mismo proceso. (github.com)

Laravel 13.36 añade una opción explícita para limpiar ese estado entre jobs. Se activa desde el proveedor de servicios y está deshabilitada por defecto. Para aplicaciones autoalojadas con réplicas de lectura y workers persistentes, es una opción que revisaría antes de asumir que las réplicas están recibiendo tráfico.

namespace App\Providers;
 
use Illuminate\Queue\Worker;
use Illuminate\Support\ServiceProvider;
 
class AppServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        Worker::$flushStickyConnections = true;
    }
}

La letra pequeña antes de actualizar

Los builders no hacen que una regla sea más estricta por sí misma: cambian cómo se declara, no qué valida. Tampoco sustituyen pruebas de integración cuando una regla depende de datos reales, DNS o restricciones de la base de datos. Conviene actualizar primero el framework y comprobar que el método elegido existe en la versión instalada antes de reemplazar reglas de texto.

olap() no convierte una consulta lenta en una consulta eficiente ni sirve para cualquier motor de base de datos. Está pensado para conexiones MySQL sobre Vitess y su ventaja es controlar el workload de forma acotada. Por otro lado, activar Worker::$flushStickyConnections puede no ser adecuado si un flujo depende deliberadamente del estado sticky entre jobs; esa dependencia merece revisarse y modelarse de forma explícita con cadenas, lotes o persistencia real.

Una actualización pequeña con impacto en código diario

No veo Laravel 13.36 como una versión para reescribir validadores por estética. Sí es una buena ocasión para limpiar reglas complejas, encapsular consultas analíticas de Vitess y revisar el comportamiento real de los workers persistentes. Son cambios pequeños, pero atacan tres zonas donde los proyectos Laravel suelen acumular detalles implícitos.

Fuente: Laravel News Documentación oficial: validación, base de datos, código del worker