DEV Community: Johan Tovar

Aprende eloquent con ejemplos!!! Lección 7 - Create y Update

Johan Tovar — Sun, 27 Jun 2021 16:59:53 +0000

Bienvenidos a una nueva entrega de Eloquent con ejemplos. Hasta ahora hemos aprendido sobre diversas funciones y herramientas que este genial ORM nos ofrece, sin embargo, no hemos visto como usarlo para persistir nuestros datos.

Al principio de la serie, vimos las diferencias entre hacer un insert() y un create(), como recordaremos, el primero ejecuta una instrucción sql que coloca los datos directamente dentro de nuestra tabla, mientras que el segundo crea una instancia de un modelo eloquent, lo que nos resulta bastante útil al momento de querer seguir usando esta información para ejecutar alguna otra lógica dentro de nuestra aplicación.

Cosas que aprenderemos:

Create y Update
Atributos fillable y guard
findOrNew
firstOrNew/firstOrCreate
updateOrCreate

Create y Update

En lecciones anteriores aprendimos como usar el QueryBuilder para insertar un nuevo registro en la base de datos, a través del uso de la facade DB:

DB::table('dogs')->insert(['name' => 'Old Yeller', 'age' => 12]);  // result "true"

Como bien lo mencionamos más arriba, esto no hace más que ejecutar una instrucción sql para persistir los datos que le enviamos en la tabla correspondiente, recibiendo una respuesta booleana que nos indica si su ejecución fue exitoso o no, y eso es todo, esta instrucción no agregará marcas de tiempo ni hará alguna otra cosa por nosotros, si necesitáramos seguir trabajando con esta data que enviamos, pues habría que ejecutar una consulta y traer el registro, o trabajar con la información en crudo tal cual la enviamos. Probemos ahora con Eloquent a ver que tal nos va y si nos puede ayudar con esta tarea:

$dog = Dog();  // result "App\Models\Dog"
$dog->name = 'Just-right Yeller'; // result "Just-right Yeller"
$dog->age = 6;   // result 6
$dog->save();    // result "true"

En este ejemplo, estamos haciendo uso del método save() que proporciona eloquent, para ello, debemos asignar los valores a cada propiedad de nuestro modelo y ejecutar el método, esto actuará de la misma manera que el insert de arriba, persistiendo nuestros datos, pero con el plus de tener una instancia de nuestro modelo, lo que nos permitirá trabajar con este registro de una manera más cómoda, pudiendo hacer casi cualquier cosa con ella. Sin embargo, podemos ver que acá trabajamos con una especie de enfoque híbrido, hemos creado una instancia del modelo, luego establecimos los atributos, para finalmente guardarlo, a grandes rasgos podríamos decir que fueron tres pasos ejecutados, veamos una tercera forma de guardar nuestra información con menos instrucciones:

Dog::create(['name' => 'Young Yeller', 'age' => 3]);

Nos ha reventado en la cara esta exception: "Illuminate\Database\Eloquent\MassAssignmentException con el mensaje 'name'" - ¿MassAssignmentException, de qué se trata?

Pues bien, aquí es donde nuestros amigos $fillable y $guard entran al juego. Eloquent, en su grandiosa misión de facilitarnos el manejo de información desde y hacia la base de datos, no solo nos proporciona métodos y propiedades para este particular, además, no brinda apoyo en cuanto a la protección en la ejecución de estas tareas, al garantizar que solo se inserten o actualicen los campos que se desean rellenar y nada más, para ello, en primer lugar tenemos a la propiedad $fillable, la cual es una especie de lista blanca, en la cual le indicamos cuales son los campos de nuestra base de datos que puede guardar a través de la asignación en masa. En segundo lugar, tenemos $guard la cual es todo lo contrario, en ella indicamos aquellos que deseamos proteger y que solo podrán ser asignados de manera directa (como en el segundo ejemplo usando save()).

Solucionemos esto y pongámoslo en marcha. Vayamos al modelo Dog y agreguemos la siguiente línea:

protected $fillable = ['name'];

Ahora desde tinker creemos un nuevo registro:

Dog::create(['name' => 'Young Yeller', 'age' => 3]);

Con esta instrucción hemos hecho lo mismo que en el ejemplo anterior, salvo una excepción, hemos cometido un error y no nos hemos dado cuenta. Si revisamos nuestra base de datos, encontraremos que efectivamente nuestro amigo Young Yeller se encuentra registrado, sin embargo, a pesar que hemos indicado su edad al momento del registro, este dato no ha persistido, ¿y por qué?, pues tan simple como que no le indicamos a $fillable que podía permitir la asignación de este campo. Este es un error muy común y de los que muchas veces tardamos en darnos cuenta debido a que en realidad no existe ninguna señal de error que así no los indique, por lo que podríamos pasar horas quebrándonos la cabeza buscando el motivo por el cual nuestros datos no persisten, muchos podrán pensar que esto es una desventaja e incluso algunos tratarían de evitar el uso de este método, sin embargo, debemos tomar en cuenta que esto es así por una razón, la ‘inyección de SQL’, de esta manera, aunque cualquier atacante intente y logre agregar campos no definidos por nosotros, estos no afectarán a nuestra aplicación puesto que serán ignorados por Eloquent.

La inyección de sql es un tipo de ataque muy común en la web, si quieres saber un poco más sobre ello, puedes hacerlo en el link: Inyección de SQL

Ahora bien, aunque hasta ahora hemos visto tres diferentes maneras de como guardar nuestros datos, aún quedan algunos otros métodos que nos ayudan en esta misma tarea, y si bien puede parecer abrumador tener que aprender tantas opciones y manera de hacer una cosa, la verdad es que cada una tiene una finalidad o ayudan de una manera distinta, solventando tipos de situaciones diferentes.
Vemos entonces una nueva forma de hacer lo anterior:

$dog = new Dog (['name' => 'Young Yeller', 'age' => 3]); // result App\Models\Dog {#690 name: "Young Yell

Como vemos, la instrucción anterior no hace más que crear una instancia del modelo Dog, mas no persiste ni crea ningún registro, si queremos que esto suceda debemos invocar al método save() desde nuestra instancia.

findOrNew, firstOrNew/firstOrCreate:

Estas tres funciones son increíblemente útiles, sin embargo, muchos desarrolladores de Laravel rehúyen de ellas como algo desconocido. No hay necesidad de hacerlo; de hecho, a estas alturas ya deberíamos tener algún entendimiento de lo que hacen.

En los ejemplos anteriores hemos visto como al hacer uso de new solo creamos una instancia del modelo, nada distinto a una simple creación de instancia desde php puro $dog = new Dog($data). Por su parte, Create también crea una instancia del modelo con la distinción de que además persiste en la base de datos la información contenida en la instancia, o lo que se podría traducir en $dog= (new Dog($data))->save(), en este sentido, podemos decir que:

findOrNew lo que hace es “Buscar un registro con la clave principal, si la encuentra la devuelve y si no crea una instancia nueva y vacía del modelo.


>>> $dog = Dog::findOrNew(100)
=> App\Models\Dog {#4061}

firstOrNew lo que hace es “ Buscar el primer registro que cumpla con la condición. Si no puede encontrar uno, crea una nueva instancia de modelo poblada con la información dada sin persistirla"

// Si existe lo devuelve
>>> $dog = Dog::firstOrNew(['name' => 'Jock'])
=> App\Models\Dog {#4284
     id: 2,
     name: "Jock",
     gender: "male",
     age: 7,
     created_at: "2021-06-07 02:05:46",
     updated_at: "2021-06-07 02:05:46",
     deleted_at: null,
   }

// Si no existe crea la instancia
>>> $dog = Dog::firstOrNew(['name' => 'Champ'])
=> App\Models\Dog {#3333
     name: "Champ",
   }

firstOrCreate lo que hace es “ Buscar el primer registro que cumpla con la condición. Si no puede encontrar uno, crea una nueva instancia de modelo poblada con la información dada y la guarda en la base de datos"


>>> $dog = Dog::firstOrCreate(['name' => 'Champ'])
=> App\Models\Dog {#4282
     name: "Champ",
     updated_at: "2021-06-27 15:26:41",
     created_at: "2021-06-27 15:26:41",
     id: 6,
   }


>>> Dog::find(6)
=> App\Models\Dog {#4287
     id: 6,
     name: "Champ",
     gender: null,
     age: null,
     created_at: "2021-06-27 15:26:41",
     updated_at: "2021-06-27 15:26:41",
     deleted_at: null,
   }

Ya los vamos entiendo, sin embargo, quizás surja la duda de ¿Por qué querríamos hacer instancias vacías? Hay algunas razones, pero una es que cuando buscamos un registro, siempre tendremos una instancia de modelo como clase de resultado, incluso si no se encuentra la que queremos, esto significa que podemos escribir nuestro código de forma más coherente y limpia, porque no tenemos que ensuciarlo con muchos condicionales por todas partes.

updateOrCreate:

Antes de terminar por hoy, veamos una última función a tener en cuenta updateOrCreate(). Esta función nos permite concluir una búsqueda de varias partes con una instrucción de inserción o de actualización dependiendo de su resultado. Por ejemplo:

Dog::updateOrCreate(['id' => 1, 'name' => 'Joe'], ['age' => 15]);

En ese caso, al igual que los anteriores, buscará un perro cuyo id se igual a 1 y su nombre sea Joe, ambas condiciones son incluyente, al encontrar una coincidencia, cambiará su edad al valor de 15, por otro lado:

Dog::updateOrCreate(['id' => 2, 'name' => 'Joe'], ['age' => 15]);

Al no existir ninguna coincidencia que satisfaga las condiciones, esta función procederá a crear un nuevo registro con la información dada, asignando el nombre Joe y la edad de 15 al id correspondiente al nuevo registro. Como vemos, esto es útil para cosas como un perfil de usuario, donde es posible que no deseemos pedirle al usuario que complete una gran cantidad de información cuando se registre, pero si mostrarle una pantalla de perfil donde pueda terminar de actualizar más tarde.

Hoy hemos visto un montón de técnicas distintas, pero a la vez muy fácil de entender e implementar, además de tener un montón de ventajas como Eloquent ya nos tiene acostumbrados, sin embargo, es importante que nos tomemos el tiempo para experimentar con cada una de ellas; ver que funciona como esperamos y lo que no, y por supuesto, tratar de hacer cualquier variación que se nos ocurra. Hay muchos más trucos que podemos usar con lo aprendido hoy, solo debemos profundizar más en nuestro aprendizaje, echarle un ojo a la documentación oficial y al mismo código de Laravel y ser creativos.

Es todo por el día de hoy, quédate atento a la próxima entrega, si tienes alguna duda puedes contactarme en mi cuenta de twitter @johantovar o déjala en los comentarios. Hasta entonces y que tengas un feliz y exitoso día.

Repositorio de práctica: jtovarto/serie-eloquent-con-ejemplo

Aprende eloquent con ejemplos!!! Lección 6 - Accesors, Mutators y Casts

Johan Tovar — Mon, 07 Jun 2021 01:52:28 +0000

¡Bienvenido a la lección seis de Eloquent con ejemplos!

Muchas veces dentro de la construcción de nuestras aplicaciones, nos encontraremos con que queremos (o debemos) mostrar cierto tipo de información en un formato determinado, y aunque muchas veces esto lo solucionaremos con el uso de un poco de CSS, código javascript o incluso “helpers” de Laravel o del propio PHP, no nos serán ajenas aquellas situaciones en donde dichos formatos requieran de cierta lógica más compleja, lo que quizás nos obligue a llenar nuestras vistas de código para cumplir con esta tarea.
En este sentido, si nos decantamos por depositar esta lógica dentro de las vistas, estaremos incurriendo en lo que se considera una mala práctica, rompiendo con una cantidad importantes de principios y estándares propio del paradigma MVC y de la programación en general, eso sin mencionar lo confusas y sucias que se verán, llevándonos a un escenario lleno de inconvenientes de cara a la escalabilidad, reusabilidad, mantenimiento y posiblemente hasta de seguridad, sin embargo, en la lección de hoy abordaremos un poco sobre algunas herramientas y trucos que nos ofrece eloquent para encargarnos de este tipo de situaciones, no solo eliminando los inconvenientes, sino que además nos aporta una gran variedad de ventajas adicionales.

Cosas que aprenderemos:

•  Accesors
•  Mutators
•  Casts

Accesors:

Como hemos visto en las entregas pasadas, para acceder a cualquier campo de nuestra base de datos lo hacemos de una manera muy sencilla, solo haciendo un llamado a la propiedad correspondiente dentro de nuestro modelo, sin embargo, muchas veces, aunque este dato esta correctamente guardado, necesitamos mostrar un formato distinto al que ya tiene, es aquí donde los accesors entran en acción y nos salvan el día. Mediante el uso de accesors podremos manipular un registro de datos mientras sigue formando parte del modelo, cambiándolo de la forma que deseemos, vamos a verlo mediante un ejemplo:

Todos los nombres de nuestros perros se encuentran registrados en letra capital, así que cambiemos eso y hagamos que siempre se muestren en mayúsculas, para ello, coloquemos el siguiente código dentro de nuestro modelo Dog:

function getNameAttribute($value){
    return strtoupper($value);
}

A simple vista, parece que solo hemos agregado un método como cualquier otro, pero en cierta forma esto tiene su magia. En primer lugar, tenemos la palabra ‘get’ que indica que queremos obtener el valor, seguido del nombre del atributo (en nuestro caso ‘name’), el cual puede variar según nuestras necesidades, finalizando entonces con la palabra ‘attribute’, todo perfectamente construido bajo una notación ‘camelCase’. Lo anterior es una convención ya establecida y debemos seguirla siempre para que todo funcione.
Ahora bien, pasemos a tinker y consultemos un registro cualquiera de nuestra tabla ‘dogs’, en el siguiente ejemplo hemos elegido a nuestro amigo ”Jock”, obteniendo como respuesta “JOCK”:

>>> Dog::find(2)->name
...
=> "JOCK"
>>>

¡Listo! así de fácil hemos modificado nuestro registro, sin usar más que un simple método y siguiendo la convención establecida para ello. No importa en que forma este guardado el nombre de nuestros amigos caninos en la base de datos, a partir de ahora, siempre se mostraran en mayúsculas donde sea que lo necesitemos, pero, algo muy importante a tener en cuenta es la palabra siempre, porque a pesar que nuestro nombre seguirá guardado en su formato original, la respuesta que obtendremos sera la modificada y esto es muy importante a la hora de necesitar trabajar con el formato original, así que debemos estar muy pendientes con eso.

Ahora bien, si bien es fácil crear y manejar un accesors, no podemos obviar que el ejemplo anterior es sumamente sencillo, con simple CSS podríamos obtener el mismo resultado, sin embargo, es evidente el mundo de posibilidades que se nos abren al usar accesors, siendo métodos en los que podemos depositar cualquier lógica y retornar un formato totalmente elaborado, incluso podríamos agregar atributos a nuestros modelos construidos a partir de la información guardada en la base de datos.

//En el modelo Dog agreguemos
function getIdWithNameAttribute($value)
{
    return "{$this->id} : {$this->name}";
}

//En tinker
>>> Dog::find(2)->idWithName
...
=> "2 : JOCK"
>>>

Así de fácil hemos agregado un atributo al modelo Dog sin que éste exista en la base de datos, algo muy útil cuando queremos crear atributos dinámicos, ayudándonos a ahorrar espacio en la base de datos y ganando reusabilidad.

Ahora que tenemos claro cómo usar nuestros accesors y las ventajas que nos brinda, trabajemos en un ejemplo diferente. Digamos que el cliente ha decido abrir una pequeña tienda y nuestro jefe nos ha encomendado el desarrollo de dicha característica. Para fines prácticos de esta lección, solo abordaremos los productos, dejando quizás las demás partes de esta tarea para futuras entregas.

Pongamos manos a la obra entonces.

Nuestra tienda, entre otras cosas debe contar con una tabla productos, la cual manejará por ahora solo unos pocos campos: id, name, slug, price y options. Ahora bien, definida nuestra entidad productos, debemos pasar a la creación de los archivos respectivos para el correcto funcionamiento, a estas alturas ya deberíamos saber cuáles son estos archivos y como crearlos: modelo, factory y seeder, ¿Lo tienes? ... estoy seguro que sí, pero si no es el caso, la invitación está abierta para revisar las entregas anteriores donde esta explicado detalladamente el paso a paso que debemos seguir.

Pues bien, con el objeto de estandarizar un poco la construcción de nuestros datos, haremos solamente el seeder y el migrations correspondiente a los productos, quedando el resto como ejercicio y práctica de cada quien. Nuestros archivos deberían verse algo como esto:

Migration

public function up()
{
    Schema::create('products', function (Blueprint $table) {
        $table->id();
        $table->string('name');
        $table->string('slug');
        $table->decimal('price');
        $table->json('options');
        $table->boolean('active');
        $table->timestamps();
    });
}

Modelo

//Product.php
//Agregar propiedades fillables

protected $fillable = [
    'name', 'price', 'active', 'options'
];

Factory

//ProductFactory
public function run()
{
    Product::factory()->create([
        'name'  => 'Collares',
        'price' => rand(1000,9000),
        'slug'  => function ($attr) {
            return Str::slug($attr['name']);
        },
        'options' => json_encode([
            'color' => $this->faker->randomElement([
                'rojo', 'azul', 'verde'
            ])
        ])
    ]);
}

Seeder

//ProductSeeder.php

public function run()
{
    Product::factory()->create([
        'name'  => 'Collares',
        'price' => 1400.5,
        'slug'  => function ($attr) {
            return Str::slug($attr['name']);
        },
        'options' => json_encode(['color' => 'azul'])
    ]);
}

Solo estamos sembrando un solo registro en nuestra base de datos, podríamos tener tantos como quisiéramos, pero para los fines del ejemplo es más que suficiente. Vayamos a tinker y consultemos nuestro producto:

>>> Product::find(1)

=> App\Models\Product {#4123
     id: 1,
     name: "Collares",
     slug: "collares",
     price: "1400.50",
     options: "{"color": "azul"}",
     active: 1,
     created_at: "2021-06-06 16:58:45",
     updated_at: "2021-06-06 16:58:45",
   }"

A simple vista todos los campos están correctos, sin embargo, para poder mostrar correctamente la información como los usuarios la esperan, debemos hacer unas pequeñas modificaciones, empecemos entonces por el campo precios. En todo sistema informático encontraremos que el formato de separación de decimales es con notación de puntos, esto está bien y es perfecto para nuestra aplicación al momento de realizar sus cálculos, pero para nuestros clientes, quienes están acostumbrados a ver una coma (,) cumpliendo con esta función y al punto (.) como separador de millares, quizás pueda ser objeto de confusión, vamos a darle entonces un formato más familiar:

En nuestro modelo Product coloquemos el siguiente accesor

public function getFormattedPriceAttribute()
{
    return number_format($this->convertedPrice, 2, ',', '.');
}

Si consultamos en tinker, veremos ahora el nuevo formato.

>>> Product::find(1)->price
=> "1400.50"

>>> Product::find(1)->formattedPrice
=> "1.400,50"
>>>

Ahora le hemos dado un formato mucho más legible a nuestros precios, sin modificar el valor original del mismo, sin embargo sigue siendo un ejemplo muy fácil aunque demostrativo del poder de eloquent, pero, si imaginamos por un momento un ecommerce internacional con manejo de precios en varias divisas, debiendo mostrarlos según las preferencias del usuario o por la región en donde se encuentra, esto nos llevaría a la implementación de una lógica que se encargue de hacer la conversión necesaria antes de mostrar los precios, sin duda un escenario en el que los accesors pueden ayudarnos:

public function getFormattedPriceAttribute()
{
    return number_format($this->convertedPrice, 2, ',', '.');
}

public function getConvertedPriceAttribute()
{
    return $this->convertPrice($this->price);
}

private function getConvertPrice ($price)
{
    //lógica para determinar preferencias
    $rate =3;

    //conversión de precio
    return $price * $rate;
}

Hemos modificado nuestro primer accesor y ahora no trabaja con el campo price directamente, sino que se vale del resultado de un nuevo accesor, para así retornar nuestro precio convertido y formateado al mismo tiempo. Tomemos en cuenta que es una implementación simple y con fines ilustrativos, son obvias las mejoras necesarias, pero queda de parte de cada uno de nosotros completar dicha tarea.

Mutators:

Los mutators son la otra cara de los accesors. Como ya vimos, con estos últimos podemos tomar los valores de la base de datos y mostrarlos de una manera distinta a su forma original, ahora con los mutators, es exactamente lo contrario, podremos capturar el valor antes de que entre en la base de datos y modificarlos antes de que sean persistidos, pudiendo hacer cosas como cifrar contraseñas, limpiar los datos, entre muchas otras tareas. Veamos un ejemplo:

function setNameAttribute($value){
    return $this->attributes['name'] = strtoupper($value);
}

Podemos ver la similitud en la construcción entre ambas herramientas, a penas y se nota la diferencia entre la antes usada palabra “get” (accesors) y “set”, propia de los mutators, es debido esta pequeña diferencia en la construcción del nombre de ambos métodos que la gente a veces se confunde, pero con práctica no se debería tener ningún problema.

Al igual que los accesors, podemos crear propiedades nuevas que no estén relacionadas con campos existente en nuestra base de datos, sin embargo, aunque no generará ningún error al momento de guardar nuestro modelo, los valores de estas propiedades no serán persistido.

Las ventajas de usar los mutators recae sobre varios tópicos, entre los cuales podemos mencionar, la facilidad con la que podemos estandarizar la información que vamos a almacenar dentro de nuestra base de datos, por ejemplo, si te fijas en el código de arriba, esta función lo que hace es guardar el nombre en mayúsculas, sin importar el formato en el que este pueda venir, algo conveniente de cara a mantener un estándar en el formato de nuestros datos.

Por otro lado, con los mutators también podemos detectar el cambio en alguna propiedad de nuestros modelos, lo que nos ayudaría en el caso de tener que modificar tanto el formato que entra a nuestra propiedad, como cualquier otra que debiera cambiar como un efecto necesario para mantener la coherencia en la información, ejemplo de ello pudiera ser los llamados ‘slugs’. Antes de pasar al ejemplo, debemos tener en cuenta que la siguiente es una forma entre muchas que existen, siendo alguna incluso más conveniente para hacer este cambio, pero para fines prácticos de la lección nos viene perfecto:

public function setNameAttribute($value){
    $this->slug = Str::slug($value);
    return $this->attributes['name'] = strtoupper($value);
}

Como es costumbre vayamos a la consola y hagamos la consulta respectiva de la siguiente manera:

>>> $product = Product::find(1)
=> App\Models\Product {#4056
     id: 1,
     name: "Collares",
     slug: "collares",
     …
   }

>>> $product->name = "Collares PARA perrOs"
=> "Collares PARA perrOs"

>>> $product->name //Nombre mutado
=> "COLLARES PARA PERROS"

>>> $product->slug  //Slug generado por el mutator
=> "collares-para-perros"

Observemos como en primer lugar, el name de nuestro producto y su slug se imprimen según el valor almacenado en la base de datos, al asignarle un nuevo nombre, nuestro mutator ha modificado el formato extraño que le hemos dado, convirtiendo toda la cadena a mayúsculas modificando al mismo tiempo el slug, manteniendo así la coherencia entre ambos datos.

Casts:

Como sabemos, los modelos de Laravel poseen una variedad de propiedades que los dotan de múltiples funciones y utilidades, siendo casts una de ella y, como bien se señala en su documentación, esta propiedad “proporciona un método práctico de convertir atributos en tipos de datos comunes”, haciendo este trabajo de manera automática al obtener y/o capturar el valor del atributo declarado, veamos cómo funciona:

>>> $product = Product::find(1)
…

>>> $product->active
=> 1

Observemos como el campo active, aun cuando en la migración esta declarado como boolean, nuestro modelo lo representa con valor int de “1”. Cambiemos esto y hagamos que active se vea como un verdadero boolean:

// En nuestro modelo
protected $casts = [
    'active' => 'boolean'
];

//En tinker
>>> $product = Product::find(1)
…

>>> $product->active
=> true

Ahora nuestro campo active dejó de verse como un tipo int y ahora luce como todo un boolean, encargándose el modelo de esta tarea de manera automática. Otra propiedad con una misión similar es dates, pero como podemos notar se enfoca solo en datos tipos fecha, sin embargo, su uso podríamos decir que es obligatorio, no porque Laravel y sus modelos así nos lo imponga, sino por los exagerados beneficios que esta nos brinda.

Cuando trabajamos con fechas, es siempre un constante dolor de cabeza el solo pensar todo lo que a ellas se refiere, desde distintos formatos de entrada y salida, necesidad de trabajar con partes específicas de ellas (como el día, mes u hora), operaciones entre ellas, validaciones, hasta un sin fin de otros inconvenientes que su uso conlleva, por suerte, existe un extraordinario paquete llamado Carbon, el cual ya tiene todo pensado y nos facilita este enorme trabajo. La razón de que hablemos de este grandioso paquete es porque, cuando declaramos un atributo dentro de la propiedad dates, nuestro modelo se encargará de tomar nuestra fecha de la base de datos y convertirla en un objeto Carbon, con esto, podremos hacer uso de todas sus ventajas haciendo nuestra vida más fácil.

Aunque en nuestro ejemplo de hoy no hemos agregado ningún atributo tipo date, basta con que sepamos que al igual que los casts, basta con declarar nuestro campo tipo fecha dentro del array dates, sin embargo, para ilustrar un poco el poder de trabajar con este tipo de objeto, podemos elegir cualquiera de los campos created_at y updated_at, (también deleted_at si estamos trabajando con softdeletes) y verlos en acción. Cuando llamamos a cualquiera de estos campos, podremos ver que los mismos son una instancia del objeto Carbon, por lo que podremos hacer cosas como estas:

>>> $product->created_at->diffForHumans(now())
=> "25 minutes before"

>>> $product->created_at->toDateString()
=> "2021-06-06"

>>> $product->created_at->addYears(5)->toDayDateTimeString()
=> "Sat, Jun 6, 2026 12:08 AM"

>>> $product->created_at->toDateTimeString()
=> "2021-06-06 00:08:39"

>>> $product->created_at->toDayDateTimeString()
=> "Sun, Jun 6, 2021 12:08 AM"

>>> $product->created_at->monthName
=> "June"

Como puedes ver, con solo tener un objeto carbon, podemos hacer un sin fin de cosas, aquí solo mostramos unas pocas utilidades, pero la invitación está abierta para revisar todo lo que este maravilloso paquete nos ofrece. Podemos visitar el siguiente enlace para CARBON y conocer un poco más sobre él.

Por último, nos queda conocer los llamados custom casts. Al igual que casts, con ellos podemos modificar el tipo de dato de nuestros campos, pero en este caso, este tipo de dato no será un tipo básico, en su lugar, será un tipo de dato construido por nosotros mediante una clase destinada a ello.

En nuestro ejemplo definimos un campo tipo json llamado options, su misión es contener información adicional del producto, la cual por conveniencia debemos guardarla en este formato, sin embargo, al momento de recuperar a información, necesitamos que esta información se comporte de una manera que ningún tipo de dato básico puede hacerlo, queremos poder moldear este comportamiento y dotarlo de ciertas mejoras que faciliten nuestro trabajo d desarrollo, para ello hagamos lo siguiente:

Paso1

Primero vamos a crear una clase que se encargue de darle cierto comportamiento a nuestro atributo. Esta clase sera un Value Object, en ella podremos darle el comportamiento que deseamos a nuestro atributo, pero no tenemos ningún comando para crearla, así que debemos proceder manualmente:

Creamos un archivo llamado OptionVO.php dentro del directorio App/ValueObjects,y coloquemos lo siguiente:

class OptionsVO
{
    protected const COLOR_HEX = [
        'rojo'  => '#FF0000',
        'verde' => '#00FF00',
        'azul'  => '#0000FF',
    ];

    public string $color;

    public function __construct($options)
    {
        $this->color = data_get($options, 'color');
    }
    public function colorHex()
    {
        return self::COLOR_HEX[$this->color];
    }
    public function toArray()
    {
        return [
            'color' => $this->color
        ];
    }

    public function toJson()
    {
        return json_encode($this->toArray());
    }
}

Básicamente, solo estamos creando un objeto con una propiedad que retorna el valor almacenado en la base de datos, un método el cual nos devuelve el equivalente hexadecimal según el color, y un par de métodos más que devuelven a nuestro objeto en un formato específico (json y array), estos últimos nos ayudarán cuando hagamos la implementación de la clase casteable. El comportamiento dado es bastante simple, además solo estamos pasando una sola propiedad, pero podemos sentirnos libres de ser creativos y agregar lo que queramos y/o necesitemos.

Los Value Object son útiles en el modelado de aplicaciones, mediante su implementación, podemos dar forma a conceptos de menor peso dentro de ellas, como pueden ser direcciones, fechas, unidades de medidas o conversión, entre otros.

Paso 2

Ahora tenemos que crear la clase que se encargará de la magia de la transformación, valiéndonos esta vez del comando creado para esta tarea, vamos a la consola y ejecutemos lo siguiente:

php artisan make:cast ProductOptionsCast

Esto creará un archivo en el directorio App/Casts, con el nombre que le demos a nuestra clase, en el depositaremos el siguiente código:

public function get($model, $key, $value, $attributes)
{
    return new OptionsVO(json_decode($value));
}


public function set($model, $key, $value, $attributes)
{
    if (!$value instanceof OptionsVO) {
        throw new InvalidArgumentException('The given value is not an OptionsVO instance.');
    }

    return [
        'options' => $value->toJson()
    ];
}

Esta clase está compuesta por dos métodos: El primero de ellos es get, este se ejecuta al momento de recuperar la información almacenada en la base de datos, la cual recordemos se encuentra en formato json, así que lo decodificamos y construimos un objeto OptionsVO a partir del resultado. El segundo es set y se activa cuando se le asigna un valor a la propiedad, que en nuestro caso es options, este debe recibir una instancia del objeto OptionsVO para que funcione, de lo contrario salta una exception.

Paso 3

Por último, debemos indicarle al modelo Product que debe modificar el tipo de dato de su propiedad options, para lo cual procedemos de la misma manera que ya vimos más arriba con respecto a $cast:

//Modelo Product.php
protected $casts = [
    …
    'options' => ProductOptionsCast::class,
];

Y con esto es suficiente, ahora podemos hacer uso de nuestro nuevo tipo options:

>>> $product = Product::find(1)
=> App\Models\Product {#3338
    ...
    options: "{"color": "azul"}",
    ...
}
>>> $product->options
=> App\Valuebjects\OptionsVO {#4267
    +color: "azul",
}
>>> $product->options->color
=> "azul"

>>> $product->options->colorHex()
=> "#0000FF"

¡Lo hemos hecho!, nuestro casts trabaja perfectamente y sin mayores complicaciones, si necesitamos agregar más comportamiento, todo se encuentra encapsulado en una sola clase, lo que facilitará muchos nuestro trabajo al momento de la integración de nuevas options.

Nota

Antes de finalizar por hoy, debemos saber que quedan algunas modificaciones que debemos hacer en cuanto a la factory y el seeder de los productos para que no se rompa la aplicación al momento de crear o sembrar nuevos registros. Queda como ejercicio el realizar dichas modificaciones, pero siempre podemos ver la solución en el repositorio de la serie.

Quédate atento a la próxima entrega, si tienes alguna duda puedes contactarme en mi cuenta de twitter @johantovar o déjala en los comentarios. Hasta entonces y que tengas un feliz y exitoso día.

Repositorio de práctica: jtovarto/serie-eloquent-con-ejemplo

Aprende eloquent con ejemplos!!! Lección 5 - Global scopes, Soft-deletes y Traits

Johan Tovar — Mon, 17 May 2021 00:49:33 +0000

¡Bienvenido a la lección cinco de Eloquent con ejemplos!

Como has podido ver a lo largo de las entregas pasadas, nos hemos enfocado en las herramientas que tenemos a disposición con el marco de laravel, esto claro con el objetivo de agilizar nuestro flujo de trabajo y así podernos enfocar en la resolución de problemas reales de nuestra aplicación. Es primordial tener siempre presente que el aprendizaje es un proceso largo y continuo, si quieres sacar el mayor provecho de todo lo que Eloquent y el marco de Laravel nos ofrece, pues no dejes de chequear la documentación oficial, seguir al tanto de las novedades que semanalmente el equipo de laravel nos revela y por supuesto de repasar y compartir el material que en estas entregas pongo a tu disposición.

Hasta ahora hemos modificado algo de nuestro código y nos hemos separado un poco de los ejemplos de la fuente original de este curso, sin embargo, la idea y esencia es la misma, pues se trata de ejemplificar con prácticas más realistas que las que nos encontramos comúnmente en diversos tutoriales. En la pasada entrega aprendimos sobre los model scopes (ámbitos locales), no sólo como una forma de agregar cláusulas where y hacer consultas, sino como una idea de organizar nuestro código. Hoy vamos a ampliar en eso mostrándote que son los global scopes (alcances globales) y la introducción los traits en Laravel.

Cosas que aprenderemos:

Global scopes
Soft-deletes
Traits

Model Scopes:

Los model scopes (alcances globales) no son "globales" en el sentido de una variable global, sino que se aplican a todos los registros de un modelo concreto como adición a cualquier otra restricción. Por lo general, estos están reservados para más restricciones a nivel de sistema y pueden funcionar junto con un trait como soft-deletes que analizaremos más adelante en esta lección o requisitos de multiinquilino (multi-tenant).

Hay dos maneras de usar global scope; creando una clase independiente o simplemente usando el propio modelo. Una clase independiente hace que el ámbito sea reutilizable, por supuesto, ya que, podría extenderla a cualquier modelo que la requiera, en el segundo solo estaría dentro del modelo donde declaremos el global scope. Veamos este último caso aplicando un global scope en nuestro modelo Dog para el manejo de edades de nuestros caninos.

En primer lugar, vayamos a nuestro modelo Dog.php e importemos la clase Builder que necesitaremos para que todo esto funcione:

use Illuminate\Database\Eloquent\Builder;

La mayoría de las clases Laravel tienen una función boot que se llama como parte de la creación de instancias de la clase. Aquí es donde normalmente registramos cosas como observables y eventos, así como agregar nuestro global scope en este ejemplo. Recuerda que debes asegurarte de llamar al método parent

protected static function boot ()
{
    //llamado al método boot padre
    parent::boot();

   //nuestro global scope
    static::addGlobalScope('age', function (Builder $builder) {
        $builder->where('age', '>', 8);
    });
}

El método addGlobalScope() admite dos parámetros, en el primero de ellos pasamos una cadena que corresponde al nombre de nuestro global scope, con la que nos referiremos mas adelante cuando necesitemos invocarlo (en este caso ‘age’), el segundo es un closure en el que especificamos las condiciones con las que filtraremos nuestra respuesta.

Con el método anterior, lo que hemos hechos es restringir nuestra consulta all() aplicando un filtro para que solo nos devuelva aquellos caninos cuya edad sea mayor a 8, de esta manera, si haz seguido el curso hasta acá, verás como al hacer la consulta obtendremos solo un resultado, la bella Jane:

// ejecutamos tinker y aplicamos la consulta

>>> App\Models\Dog::all();

=> Illuminate\Database\Eloquent\Collection {#4057
     all: [
       App\Models\Dog {#4058
         id: 4,
         name: "Jane",
         gender: "female",
         age: 9,
         created_at: "2021-05-02 23:13:42",
         updated_at: "2021-05-02 23:13:42",
       },
     ],
   }

Como podrás ver, no hemos usado ningún método adicional como si lo hicimos en la entrega pasada con los local scopes, acá solo le indicamos a la aplicación que nos devuelva TODOS los registros de nuestros modelos, siendo ese “todos” aquellos registros que cumplen con la condición definida.

En tal sentido, es importante dejar claro, que a partir de la declaración de este global scope, nuestra aplicación siempre ignorará cualquier otro registro que no cumpla con el criterio dado, por lo que cada vez que invoques al modelo Dog, este solo tomará en cuenta aquellos que si lo cumplen, veámoslo con un ejemplo:


//Solicitamos el perro con ID 2 cuya edad es 7
>>> App\Models\Dog::find(2);

//Obtenemos null
=> null

Como podrás observar, al hacer una consulta sobre un registro específico, en este caso el ID con valor 2, la respuesta obtenida es null, a pesar que en nuestra base de datos esta registrado nuestro amigo Jock, esto debido a que no cumple con el criterio establecido, lo mismo ocurrirá con el llamado a otros métodos como el de actualizar el registro, así que ten esto presente cuando vayas hacer uso de esta útil herramienta.

Ahora bien, a pesar del comportamiento explicado arriba, aún es posible acceder al verdadero TODOS de nuestra tabla dogs, entiéndase el resultado que obteníamos ante de la declaración de nuestro global scope, para ello podemos hacer uso de la siguiente instrucción:

// trae todos los 4 registros
App\Models\Dog::withoutGlobalScope('age')->get();

Ahora si obtendremos todos los registros contenidos en nuestra tabla, tal y como lo habríamos obtenido con un simple all() sin la declaración del global scope. Presta atención al hecho de que al método withoutGlobalScope() pasamos como parámetro el nombre del scope, algo perfectamente útil si tenemos varios scopes declarados y solo queremos eludir alguno(s) de ellos.

Es una recomendación obligatoria el dejar notas y/o comentarios dentro del modelo explicando el uso de los global scope que declaramos, esto con la finalidad de no crear dudas sobre posibles resultados que se obtengan al hacer consultas o cualquier otra acción que se vea afectado por dichos scopes, resultaría bastante frustrante para cualquier desarrollador el no poder entender porque no obtiene la respuesta esperada, lo que llevaría quizás mucho tiempo escudriñando y realizando pruebas para dar al fin con la causa. Puede parecer obvio cuando está leyendo este sencillo ejemplo, pero agregue DocBlocks, anotaciones y todas las demás capturas que encuentre en un código base en vivo real y evitar pérdida de tiempo valioso en un futuro!

Soft-deletes:

Todos saben que es mejor no eliminar los registros de la base de datos, ¿verdad? Puede sonar un poco a broma puesto que muchos programadores de bases de datos son un anatema respecto a borrar cualquier cosa, pero es un asunto serio. En realidad, la eliminación de registros - especialmente accidentalmente - puede conducir a todo tipo de problemas, como registros huérfanos y falta de datos históricos para su análisis. Es mucho mejor práctica "marcarlos" como activos o no. Sin embargo, hacer esto significa agregar un campo "active_flag" en todas las tablas y luego recordar ponerlo en todas las cláusulas where. No es lo ideal. Lo bueno es que laravel ya lo tiene resuelto ¡Global scopes!

Debido a que este tipo de global scope es tan universalmente deseado, Laravel ha hecho lo que Laravel hace mejor - han preparado una solución fácil de usar llamada "Soft Deletes". Funciona entre bastidores, en combinación con algunas funciones adicionales, para marcar los registros eliminados con un campo de marca de tiempo llamado "deleted_at". ¡Incluso hay una función de migraciones para agregar esto!

Aunque soft-deletes trabaja como un global scope, su configuración es ligeramente diferente a como te mostré más arriba, así que echemos un vistazo rápido.

Debemos empezar por agregar el campo correspondiente en nuestra migración. Aunque podemos agregarlo dentro de la migración existente, es recomendado siempre ir paso a paso y crear un nuevo archivo que lo haga, así llevamos una secuencia de la evolución de nuestras migraciones y por ende de nuestra aplicación, así que vayamos a la terminal y ejecutemos:

php artisan make:migration add_softdeletes_to_dogs_table

Esto creará nuestro un archivo migrations, vamos a abrirlo y coloquemos lo siguiente:

class AddSoftdeletesToDogsTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::table('dogs', function (Blueprint $table) {
            $table->softDeletes();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::table('dogs', function (Blueprint $table) {
             $table->dropSoftDeletes();
        });
    }
}

Ya solo queda correr nuevamente el comando migrate (a estas alturas ya debería saber cómo), y listo, si revisas la base de datos veras que se ha agrado un nuevo campo a la tabla dogs: deleted_at, el cual acepta valores NULL.

Como siguiente paso, debemos indicarle a nuestro modelo Dog que haga uso de esta función y del nuevo campo, para ello, demos ir hasta él y agregar lo siguiente:

//importamos la librería
use Illuminate\Database\Eloquent\SoftDeletes;

class Dog extends Model
{
    //Invocamos el trait
    use SoftDeletes;

También queremos que el campo deleted_at sea una instancia del objeto Carbon. Esta es una característica realmente encantadora de Laravel. Para hacer esto, solo tenemos que agregar cualquier campo fecha al atributo $dates en la parte superior del modelo de la siguiente forma:

protected $dates = ['deleted_at'];

Cualquier campo tipo fecha que coloques dentro de este array se convertirá en una instancia de clase Carbon. Esto te da una multitud de funciones fáciles de trabajar cuando necesitas formatear, comparar o manipular fechas. Si quieres saber más (y sugiero que lo hagas) pues revisar la documentación de Carbon en su sitio oficial.

¡Eso es todo! ¡Ya terminaste! El uso de la función Eloquent delete() marcará automáticamente el timestamp de ese registro como eliminado, y ya no aparecerá en ningún resultado a menos que ignore específicamente el ámbito, esto es porque soft-deletes actua filtrando todos los registros que tengan el campo deleted_at igualo a NULL y devolviéndolos. Todas las instrucciones que hacen posible el trabajo de soft-deletes, se encuentran depositadas en el trait que invocamos dentro de nuestro modelo, lo que la hace totalmente reutilizable y adaptable a cualquier modelo que tenga tu aplicación. Como nota importante a este punto, te recomiendo que evites actualizar el campo deleted_at manualmente, si quieres ver como manipular este campo y/o ver como adaptar esta herramienta a tus necesidades, deberías dirigirte a la documentación oficial de laravel sobre soft-deletes o darle un ojo al trait, siempre es bueno y muy educativo leer el código que otros escriben.

Traits:

Tendemos a usar traits en Laravel para agrupar funciones relacionadas, incluso si no están destinadas a ser reutilizadas con otras clases. Si abres SoftDeletes en tu IDE, verás un ejemplo en el que claramente se están reutilizando, pero en casos como el sistema de autenticación, que también se basa en traits, se usan para mantener todas las funciones de contraseña, funciones de restablecimiento, entre otras, juntas para un espacio de trabajo más limpio.

Los traits no son parte de laravel en sí mismo, pues son un elemento directo del propio PHP, en ellos no hay secretos ocultos o clases abstractas de las que se deba heredar. Su utilidad es bastante amplia, pues nos permite depositar nuestra lógica dentro de ellas y poder ser reutilizada donde sea que se necesite. Para usar un trait solo basta con crearlo (normalmente en un nuevo directorio Traits), e importarlo en la clase que lo necesite a través del "use FooTrait" en la parte superior y listo.

Su uso es muy versatil, por ejemplo es muy común para mi usarlo en los modelos, en particular he trabajado en varios proyectos en donde se ha hecho necesario que el ID de las tablas sean mucho más complejos que un simple entero incremental, o también que contengan un campo slug, este tipo de necesidades siempre las soluciono a través de un trait, lo que me permite reutilizar el mismo código en todos mis modelos estando depositado este en un solo lugar y solo siendo invocado en donde lo necesito, así de simple, también son usados a menudo en controladores como funciones auxiliares, lo que permite que el controlador simplemente enumere las funciones principales de ruta y cambie todas las funciones de "acción" a una clase de servicio independiente. Esto realmente se reduce a tu propio estilo y preferencia – toma solo lo que tenga sentido para ti y te ayude a mantener tu código limpio.

Espero que estas primeras lecciones te estén ayudando a crear confianza con las herramientas que Laravel ofrece, puestas allí para ayudarte, y que estés empezando a ver cuánto puedes mejorar y ser más productivo en tus aplicaciones si confías en ellas.

En las próximas entregas vamos a estudiar la presentación de nuestros datos, así como la creación y actualización de registros, algunas técnicas más avanzadas con where() y un primer vistazo a las relaciones.

Quédate atento a la próxima entrega, si tienes alguna duda puedes contactarme en mi cuenta de twitter @johantovar o déjala en los comentarios. Hasta entonces y que tengas un feliz y exitoso inicio de semana.

Nota

Aprovecho para compartir un pequeño repositorio de lo que hemos visto hasta ahora, la verdad todo ha sido muy sencillo, sin embargo, para quienes quieran hacer sus propias pruebas o revisar algo que quizás se les haya escapado, pues les dejo el link del repositorio, espero les sea de ayuda.

Aprende eloquent con ejemplos!!! Lección 4 - Model Scopes

Johan Tovar — Mon, 03 May 2021 01:12:44 +0000

Bienvenidos de nuevo a “Eloquent con ejemplos”, en la pasada entrega aprendimos los conceptos básicos de los Modelos y una nueva herramienta llamada Tinker. Hasta ahora hemos tocado solamente un poco de la superficie de Eloquent y su funcionamiento, como habrás notado, a pesar de que este es un curso de Laravel, todavía no hemos construido ninguna ruta o páginas web!

Laravel es un ecosistema muy grande que abarca mucho más que las páginas web estándar. Aprender a mirar una sección aislada de ella, como lo estamos haciendo con Eloquent, será muy útil para desarrollar tanto nuestra velocidad y flujo de trabajo, como nuestra comprensión de cada uno de ellas, por lo tanto, seguiremos trabajando con la línea de comandos y Tinker por un tiempo más. Puede sentirse un poco incómodo si no estás acostumbrado a trabajar de esta manera, pero al final tendrá grandes beneficios.

En esta lección vamos a empezar a hacer algunas consultas de base de datos!

Cosas que aprenderemos:

Model scopes

Uno de los mayores objetivos de esta serie es ayudar a las personas a ser competentes, y no sólo conocedoras, sobre el uso de las herramientas artisan, es por ello que repasaremos una vez más como construir nuestras tablas y datos. ¡No te preocupes, solo será un repaso y lo haremos rápidamente!

1) Aquí hay un comando que aún no hemos utilizado con migrate - "reset". Esto revertirá todas las migraciones para que podamos empezar de nuevo.

php artisan migrate:reset

2) Eliminemos los archivos creados en entregas pasadas:

El factory DogFactory
El seeder DogsTableSeeder
El modelo Dog
La migración _create_dogs_table

Probablemente deberías ejecutar en la terminal composer dump-autoload, ya que los archivos a veces se registran en el cargador automático y causan problemas más adelante cuando están "desaparecidos".

3) ¿Recuerda cómo hacer la migración y el modelo al mismo tiempo? ¡Espero que si!, igual aquí tienes la respuesta:

php artisan make:model Dogs -mfs

Esto crea nuestro modelo, junto con la migración, factory y seeder respectivamente.

4) En nuestra migración, queremos que los perros tengan un nombre, un género y un campo de edad. Agrega a la función up() dichos campos, de manera que te quede así:

public function up()
{
    Schema::create('dogs', function (Blueprint $table) {
        $table->increments('id');
        $table->string('name');
        $table->string('gender')->nullable();
        $table->integer('age')->nullable();
        $table->timestamps();
    });
}

5) Para este ejercicio, todos deberíamos tener los mismos datos para que podamos hacer algunas consultas específicas, por lo que usaremos model factories para crear introducir datos semillas en lugar de usar Faker. Vayamos a nuestro DogSeeder y coloquemos el siguiente código:

Nota: Aunque usamos model factories, no la configuraremos todavía como es debido, si embargo esto no impedirá que la usemos sin problemas. En proximas lecciones nos dedicaremos a establecer nuestra factory como es debido.

public function run()
{
    Dog::factory()->create(['name' => 'Joe', 'age' => 5 , ‘gender’ => ‘male’]);
    Dog::factory()->create(['name' => 'Jock', 'age' => 7, ‘gender’ => ‘male’ ]);
    Dog::factory()->create(['name' => 'Jessie', 'age' => 2, ‘gender’ => ‘female’ ]);
    Dog::factory()->create(['name' => 'Jane', 'age' => 9, ‘gender’ => ‘female’ ]);
}

1) Configuremos el archivo seeder central para que ejecute nuestro nuevo DogSeeder. Para esto, debemos ubicarnos en el archivo database\seeders\DatabaseSeeder y hacer la siguiente invocación:

public function run()
{
    $this->call(DogSeeder::class);
}

7) Finalmente ejecutemos nuestras migraciones junto con los archivos seeders:

php artisan migrate --seed

Model scopes:

Muy bien, ejecutemos Tinker y empecemos a consultar!

Tenemos perros de cuatro edades distintas (2, 5, 7 y 9 años), dos de ellos son hembras y dos son machos. Nos gustaría ver a todos los perros mayores de 6 años. La forma sencilla de hacer esto es simplemente poner una cláusula where() en nuestro modelo Dog, así:

php artisan tinker
Psy Shell v0.10.8 (PHP 8.0.5 — cli) by Justin Hileman

App\Models\Dog::where('age', '>', 6)->get();

Deberías ver a los encantadores Jock y Jane en pantalla.

Algo que confunde a muchas personas cuando comienzan con Eloquent es el hecho de que este se basa en QueryBuilder, pero los resultados vuelven como un objeto Collection. Esto significa que vas a encontrarte con muchas funciones con nombre similar que parecen ser diferentes dependiendo de si estás creando la consulta o manipulando los registros devueltos. En este caso estamos utilizando where() para crear una cláusula where en nuestra consulta, no para filtrar el conjunto de resultados. Para este curso usaremos las funciones querybuilder para crear instrucciones sql, te recomiendo ampliar mas sobre el tema en la documentación oficial de Laravel sobre las Query Builder.

El código que acabamos de ejecutar funciona, pero tiene algunos problemas desde el punto de vista de diseño y mantenimiento. Con este código en nuestro controlador es como si estuviéramos codificando instrucciones sql en toda nuestra aplicación. Imagina que comenzamos a usar dicha instrucción en varios lugares de nuestra aplicación, podría darse el caso que esa edad cambie por alguna razón, obligándonos a tener que a cambiarla en todos y cada uno de esos lugares, tarea bastante tediosa y poco práctica, sin mencionar que podríamos saltarnos uno o varios de ellos, generando posibles errores e inconsistencias. Por otra parte, tampoco dicha instrucción no explica el por qué usamos esa edad en específico o cuales son sus casos de uso y/o de aplicación.

Usemos algo llamado "scopes" para hacer una restricción más limpia.

class Dog extends Model
{
    function scopeAgeGreaterThan($query, $age) {
        return $query->where('age', '>', $age);
    }

    function scopeGender($query, $gender) {
        return $query->where('gender',$gender);
    }
}

Como puedes ver, tenemos dos métodos arriba que siguen a una convención de nomenclatura muy específica, un subproceso común en Laravel. La función debe comenzar con "scope" y el primer parámetro será la instancia de QueryBuilder inyectada, dicho argumento puede tener cualquier nombre que quieras darle, pero normalmente $q o $query se utiliza para mayor claridad, depende de ti el nombre y la cantidad de parámetros subsecuentes que quieras inyectar, recomiendo el uso de nombre descriptivos como $age o $gender que dan una idea clara de la razón de su existencia dentro de cada método. Ahora puedes utilizar esta función de esta forma (reinicia la sesión de Tinker para que actualice los último cambios):

App\Models\Dog::ageGreaterThan(6)→get();

Aquí hemos usado el primero de nuestros scopes, observa la respuesta en pantalla y verás que es exactamente la misma que hemos obtenido anteriormente, ¿la diferencia?, podremos usarla en cualquier parte de nuestra aplicación, con el plus de solo tener que modificarla en un solo lugar. Por otro lado es bueno mencionar que los scopes toman una instancia de QueryBuilder y la retornan, lo que permite encadenar cualquier cantidad de funciones como varios where(), orderBy(), entre otros. Veamos un ejemplo claro.

Vamos a nuestro modelo, y agreguemos:

App\Models\Dog::ageGreaterThan(6)->gender('female')->get();

Fácilmente hemos filtrado nuestro primer resultado y ahora solo nos aparece la hermosa Jane en pantalla, sin clausulas where visibles ni largas líneas de código, todo muy limpio, compacto y totalmente reusable. ¡Genial!

En la documentación oficial de laravel encontrarás un apartado dedicado al uso de clausulas where y lo que ellos llaman logical-grouping. Recomiendo encarecidamente su lectura, te será de mucha ayuda.

Esto es agradable, sin embargo todavía no está muy claro cuál es el propósito de dichos scopes, así que, vamos a darles un sentido: Digamos que a cierta edad, nuestro amigos caninos requieren de un tratamiento especial que les ayudará en su calidad de vida cuando lleguen a una edad avanza, ademas, este tratamiento es diferente según su género. Bajo este supuesto, vamos a hacer algunos cambios en nuestro modelo:

class Dog extends Model
{
    function scopeAgeGreaterThan($query, $age) {
        return $query->where('age', '>', $age);
    }

    function scopeGender($query, $gender) {
        return $query->where('gender',$gender);
    }

   function dogsForSpecialTreatment($gender) {
        return $this->AgeGreaterThan(6)->gender($gender);
    }
}

Reiniciemos tinker una vez mas:

(new App\Models\Dog)->dogsForSpecialTreatment('female')->get();

Resaltemos un par de cosas en el código de arriba. Tenemos un método común dogsForSpecialTreatment($gender) en nuestro modelo, el cual hace uso de scopes dentro de sus instrucciones, creando la consulta necesaria para cumplir con los requerimientos de nuestro tratamiento especial, puedes jugar cambiando el género y verás como se alterna el resultado entre Jock y Jane. Es importante destacar que ahora nuestro modelo tiene un método más descriptivo, cuyo nombre denota un propósito bien definido. Por otro lado, observa que al hacer uso de este método, ya no lo hacemos de la misma forma que con nuestros scopes, pues a este último accedemos mediante la forma static::, mientras que a nuestro nuevo método accedemos como a cualquier método de clase común, debiendo para ello crear una instancia de nuestro modelo usando new.

El ejemplo anterior se mantiene intencionalmente simple, y por lo tanto, si te preguntas ¿Por qué no hacer un solo **scope 'dogsForSpecialTreatment()' con toda la lógica dentro de él?** , pues dejame decirte que estas en lo cierto y tiene sentido. Sin embargo, las aplicaciones del mundo real suelen tener un conjunto de criterios que definen un cierto estado o grupo (por ejemplo, límites de edad o el género), los cuales en algún punto dado, como algún tipo de reporte, se necesita trabajar con algún tipo de subconjunto derivado (todos los perros mayores de 6 años y que sean hembras). Si piensas en diseñar y crear tus modelos a partir de piezas más granulares, en lugar de una gran función completa y monolítica, facilitará el mantenimiento de tus aplicaciones, te mantendrá alejado de la duplicación de código e incluso te ayudará a darle un significado explícito que exprese que es lo que hace, algo de bastante ayuda para cuando vuelvas a hacer cambios unos meses más tarde.

La siguiente lección introducirá alcances globales (global scopes), así como los ámbitos Laravel incorporados, como soft-deletes. No seguiremos repitiendo todos los pasos de reconstrucción cada día, así que vuelve a esta lección si necesitas ayuda para recordar cómo restablecer la base de datos para lecciones posteriores.

Quédate atento a la próxima entrega, si tienes alguna duda puedes contactarme en mi cuenta de Twitter @johantovar o déjala en los comentarios. Hasta entonces y que tengas un feliz y exitoso día.

Aprende eloquent con ejemplos!!! - Lección 3: Modelos, Tinker y Base de datos heredadas

Johan Tovar — Sun, 25 Apr 2021 21:45:06 +0000

Bienvenidos a esta tercera entrega de Eloquent con ejemplos. En la lección pasada aprendimos como poblar de una forma bastante práctica y cómoda nuestra base de datos, dándonos la oportunidad de conocer un poco sobre una pieza fundamental dentro del mundo de Eloquent: Modelos.

Hoy trataremos de indagar más a fondo dentro de esta importante clase y aprenderemos sobre su gran versatilidad para interactuar con base de datos nuevas y heredadas, conoceremos sobre algunos de sus atributos y uno que otro tip de configuración que nos ayudarán a crear aplicaciones de manera rápida y mantenibles.

Lo que aprenderemos hoy:

Atributos de los Modelos.
Tinker.
Trabajar con base de datos heredadas.

Empecemos por un pequeño repaso de lo visto en la lección pasada sobre los modelos y partamos de lo que ya habíamos hecho.

Si revisamos nuestra aplicación vemos que se nos había solicitado la creación de un tabla dogs, procediendo a crear nuestro modelo Dog en la terminal y pasándole los respectivos flags de creación de migraciones, factories y seeders, a estas alturas ya deberías saber de que te estoy hablando, si no, échale una ojeada a la entrega anterior.

Recuerda que es importante el uso correcto de las mayúsculas y minúsculas, así como el manejo de las palabras en singular y plural según sea el caso.

Pues bien, teniendo todo previamente configurado, vayamos a la consola y ejecutemos:

    php artisan tinker

Veremos como nuestra terminal ha cambiado, mostrándonos el siguiente mensaje:

Lo que hemos hechos es ejecutar una grandioso REPL (Read-Eval-Print-Loop) llamada Tinker, el cual viene instalado por defecto con Laravel 8, con el, podremos interactuar con nuestras aplicaciones desde nuestra terminal, permitiéndonos hacer pruebas o revisar el funcionamiento de lo que en ellas vamos creando, esto incluye por supuesto a nuestro modelos. ¡No más llenar nuestra base de código con llamadas dd()!

Veamos un ejemplo y ejecutemos la siguiente instrucción:

   $dog = App\Models\Dog::find(1)

   $dog->name

   => “Jack”

Verás como en pantalla aparecerá el nombre de nuestro amigo canino guardado con el id = 1. Como el nombre lo asignamos en nuestro model factory mediante el uso de la librería Faker, este será diferente para cada uno de nosotros, lo importante acá es que te aparezca un nombre, eso indica que la configuración que hicimos trabaja perfectamente y que tu modelo esta bien configurado.

Puedes ir jugando con tus modelos desde esta terminal, debes saber que Tinker recuerda nuestras variables durante una sesión de trabajo, para salir de ella y volver a nuestra consola solo debes teclear exit y listo. Cuando ingreses nuevamente deberás crear todas tus variables y configurar el entorno que tenías en la sesión anterior, pero ten presente lo siguiente: Toda interacción con la base de datos de inserción, edición y eliminación será registrada en ella de manera permanente, ten en cuenta esto al momento de realizar tus pruebas, no querrás cambiar algo que quizás necesites más adelante.

Ahora bien, hasta acá todo ha ido bien, pero no se si te haz preguntado, ¿Que pasa si nuestra aplicación viene trabajando con una base de datos heredada? ¿Es posible trabajar con mis nuevos modelos y conectarlos a esta base de datos? ¿Es eloquent tan versátil y adaptable como para brindarnos tal facilidad?. La respuesta a todo eso es SI!.

Algunas veces nos encontraremos en situaciones en la que heredamos una base de datos cuya estructura no se adapta exactamente a nuestra aplicación actual o a nuestro marco de trabajo en si, debiendo tomar decisiones que quizás no sean muy convenientes o que incluso necesiten de modificaciones difíciles y/o costosas. Sin embargo, con eloquent, en la gran mayoría de los casos, no es más que hacer unas pequeñas configuraciones y todo estará listo de una manera rápida, fácil y mantenible.

Para poder cubrir bien el ejemplo que te mostraré, deberás ir a tu base de datos y crear la tabla correspondiente e insertar al menos un registro en ella. Te dejo el código SQL por si quieres hacer uso de él, aunque la puedes crear manualmente sin ningún inconveniente.

CREATE TABLE `TblContacts`
(
`Contacts_ID` INT NOT NULL AUTO_INCREMENT ,
`Contacts_Name` VARCHAR(50) NOT NULL ,
`Contacts_Email` VARCHAR(50) NOT NULL ,
PRIMARY KEY (`Contacts_ID`)
) ENGINE = InnoDB;

INSERT INTO `TblContacts`
(`Contacts_ID`, `Contacts_Name`, `Contacts_Email`)
VALUES ('1', 'Jeff', 'jeff@codebyjeff.com');

Veamos un ejemplo:

Supongamos que nuestra aplicación tiene una tabla llamada TblContacts, lo que a primera vista denota la imposibilidad de poder hacer uso de la lógica de reflexión que Laravel nos ofrece, pues no se ajusta al standar de nombre al que tantas veces he hecho referencia. Sin embargo, vayamos a nuestra terminal para crear nuestro modelo y tratar de interactuar con ella:

    php artisan make:model Contact

Abramos Tinker y ejecutemos la siguiente instrucción:

    App\Models\Contact::all()

Vemos como rápidamente nos salta un enorme mensaje de error, en el que, en resumidas cuentas, nos esta indicando que la tabla contacts no existe, pues nuestra tabla realmente se llama TblContacts . Ahora bien, ¿como hacemos entonces para que nuestro modelo puede enlazarse con dicha tabla? . Pues esto y mucho más podemos hacerlo a través de los atributos de clase de los modelos.

Todos nuestros modelos tienen un conjunto de atributos y métodos que nos facilitarán su configuración, dándonos esa versatilidad de uso que necesitamos para adaptarnos a cualquier situación que se nos presente, en este caso, una base de datos heredada.

Pues, pongamos manos a la obra y configuremos nuestra tabla para que, al usar nuestro modelo Contact este interactúe con nuestra tabla heredada TblContacts. Vayamos a nuestro modelo y agreguemos la siguiente propiedad:

Creo que no he hecho mención a que desde la ultima versión de laravel, nuestro modelos se encuentran en App\Models\ a diferencia de versiones anteriores, en las que puedes encontrarlos en App\. Ten en cuenta esto al momento de trabajar con tus modelos.

class Contact extends Model
{
    protected $table = 'TblContacts';
}

Prueba tu comando Tinker otra vez (tendrás que salir de Tinker y abrirlo de nuevo, lamentablemente las sesiones de Tinker no detectarán cambios de código), verás que devuelve una colección (el objeto devuelto estándar de Eloquent) con una única instancia de modelo del registro que insertamos "Jeff".

Vamos a probar una idea más en Tinker - vamos a obtener el número de contacto 1. ¿Qué crees que pasará?

App\Contact::find(1)

"Illuminate\Database\QueryException with message 'SQLSTATE[42S22]: Column not found: 1054 Unknown column 'TblContacts.id' in 'where clause' (SQL: select * from TblContacts where TblContacts.id = 1 limit 1)'"

Como era de esperar, está buscando una clave principal llamada id y no la encuentra, pues la clave primaria de nuestra tabla es Contacts_ID. Eloquent nos ofrece la misma solución fácil y limpia que para nuestra tabla:

class Contact extends Model
{
    protected $table = 'TblContacts';

    protected $primaryKey = 'Contacts_ID';
}

y las cosas funcionan bien de nuevo.

Como podrán ver, la forma en la que podemos configurar nuestros modelos nos abre un abanico de posibilidades, algunas serán para buenas prácticas, otras no lo serán tanto, todo depende de nosotros y el uso que le demos, pero la verdad es que, de la forma en la que se plantean estas configuraciones podremos jugar a nuestras anchas, asignando los valores correspondiente a cada propiedad de clase según nuestra conveniencia.

Existen muchas otras propiedades de clase que podamos modificar para cambiar el comportamiento de nuestro modelos, por ejemplo, las claves primarias por defecto son de tipo enteros auto-incrementales, esto lo podemos cambiar a través de la propiedad:

class Contact extends Model
{
    protected $keyType = 'string';

    public $incrementing = false;
}

Con este cambio le estamos indicando a nuestro marco que el modelo tiene una clave primaria tipo ‘string’ que no se auto-incremental, lo que es muy útil si queremos ser nosotros quienes generemos nuestras propia claves primarias. Otra propiedad muy importante es protected $connection = 'sqlite';
, con ella podemos cambiar la conexión a la base de datos, según las configuradas en nuestro archivo config\database.php, en este caso, activamos la conexión para sqlite, pero esta y otras propiedades las dejaremos para otras entregas más avanzadas y especificas del curso.

Como último tip de esta entrega, me gustaría enseñarte como hacer para deshacernos de ese arcaico esquema de nombres heredado de nuestra base de datos. Si bien es cierto que hasta ahora todo funciona para nosotros, no debería escapársenos el hecho que los actuales campos de nuestra base de datos fueron construido bajo un esquema de nombres bastante arcaico y lejos de los standares que hoy en día manejamos. El problema al que nos enfrentamos es este: si empezamos a construir nuestra aplicación, nos encontraremos por doquier algo como esto $contact->Contacs_Name, lo que supondría, en un futuro, un trabajo de refactorización bastante laborioso. Realmente nos gustaría poner otra capa entre nuestro modelo y la salida que eventualmente usaremos en las vistas, más acorde a los standares y que sea fácilmente mantenible.

Por un lado, podemos declarar, dentro de nuestro modelo, un método de acceso a nuestra propiedad, algo muy propio de la Programación Orientada a Objetos (POO), este podría ser un ejemplo:

public function contactName(){
    return $this->Contacts_Name;
}

Ahora podremos acceder a nuestro valor haciendo uso de $contact->contactName(). Esto nos permitirá en un futuro, poder cambiar la salida de nuestro atributo sin que tengamos que hacer ninguna otra modificación dentro de nuestra aplicación. Otra manera de hacer esto mismo puede ser con el uso de los Accesors, pero eso ya es tema de otra lección más delante.

Existen otras formas como lo es el uso de un objeto completamente independiente llamado "transformador" que tiene el trabajo de presentar sus datos. Un popular paquete que ayuda a esta implementación es "Fractals", por otra parte, si estas trabajando con API’s, un recurso muy recomendado para esta tarea son los Eloquent: API Resources. Ambas implementaciones escapan del ámbito que esta lección pretende abordar, pero realmente son bastante sencillas, así que te invito a que le eches una ojeada a las fuentes si te interesa ampliar más sobre ellas.

Pues bien, esto ha sido todo por hoy, hemos aprendimos un poco sobre cómo funciona nuestro modelo, y cómo podemos controlarlo para usar tablas heredadas y esquemas de nomenclatura, así como algunos tips para enmascarar la salida de nuestros modelos. Empieza a hacer tus pruebas y jugar con el código, recuerda que el verdadero aprendizaje se da a través de la práctica, si tienes alguna duda o comentario no dudes en contactarme. Que tengas un feliz y exitoso día.

Aprende eloquent con ejemplos!!! - Lección 2: Faker, Factories, Seeders

Johan Tovar — Mon, 19 Apr 2021 04:24:24 +0000

En la entrega primera entrega de Aprende eloquent con ejemplos!!!, vimos como crear y usar de una manera bastante básica nuestras migraciones y seeders, por lo que en esta lección les enseñaré como podemos darle un mejor uso y hacer que trabajen de manera integral de cara a un flujo de trabajo más eficiente en nuestro desarrollo, para ello, aprenderemos sobre:

Factories
Faker

Empezaremos con destruir nuestra migración hecha en la lección pasada, pero debes recordar que aunque podemos ir y borrar nuestro archivo migrations, eso nos causaría muchas dificultades y molestias, razón por la cual debes proceder a ejecutar en consola el comando:

    php artisan migrate:rollback

De esta manera regresaríamos nuestra base de datos a su estado inicial, eliminando la tabla dogs registrada anteriormente. Hecho esto, podemos ahora si proceder a borrar nuestro archivo migrations sin temor de dificultades, vayamos al directorio respectivo y eliminar el archivo <timestamp>_create_table_dogs.

Con rollback devolvimos todas las migraciones ejecutadas, pudimos haber usado el flag --step=1 y solo eliminar nuestra table dogs dejando las demás intactas. Recuerda que el comando migrate tiene varias opciones, tomate tu tiempo para repasarlas y probar con ellas.

En este momento tenemos nuestra base de datos y migraciones en su estado inicial, así que ya podemos dar inicio con nuestra lección. En este sentido, y como una necesidad para poder trabajar con los elementos listados mas arriba, debemos abordar primero un concepto fundamental dentro del mundo de eloquent, el cual paso de seguida a explicarte de que se trata.

Conociendo los Modelos

En la pasada lección creamos una tabla y luego insertamos datos en ella a través de nuestro seeder, pero para el momento no contábamos con un modelo Laravel para nuestra tabla dogs así que tuvimos que hacer uso de la facade DB para poder crear nuestro registros.

Un modelo Laravel es importante para nosotros porque es algo más que una forma de interactuar con nuestra base de datos; es una parte fundamental de nuestro ORM Eloquent y nos ayudará a construir relaciones con otros recursos, establecer eventos que se disparan cuando hacemos ciertas acciones y una serie de otras cosas que estaremos aprendiendo en este curso.

Así que, teniendo nuestra base de datos como un lienzo en blanco, arrancaremos esta vez haciendo uso de este importante recurso, cuyo comando de creación es el siguiente:

    php artisan make:model Dog

pero como te prometí enseñarte un mejor flujo de trabajo, no sólo una serie de comandos, en lugar del anterior comando, ejecutaremos el siguiente:

    php artisan make:model Dog -fm

A diferencia del primer comando, esta vez le hemos pasado los flags -fm, lo cual creará no solamente el modelo Dog, si no que además se desencadenan una serie de acciones: se creará el archivo DogFactory ubicado en el directorio database/factories, también creará nuestro archivo migration en su respectivo directorio. Ve y abre este último, agregale el campo "name" y ejecuta la migración.

En este momento tenemos un modelo muy simple en el que nos sumergiremos más en la próxima lección. Por ahora, volvamos a nuestra clase DogsTableSeeder. En lugar de usar la facade DB, vamos a recrear esta siembra con el nuevo modelo. Se ve muy similar, pero usamos en su lugar el model factory que acabamos de crear, deberíamos tener algo como esto:

    public function run()
    {
        Dog::factory()->create(['name' => 'Joe']);
        Dog::factory()->create(['name' => 'Jock']);
        Dog::factory()->create(['name' => 'Jackie']);
        Dog::factory()->create(['name' => 'Jane']);
    }

fig. 1

Ejecute esto con:

    php artisan db:seed –class=DogsTableSeeder

y mira los resultados en la tabla.

Si haz seguido los pasos hasta acá, verás como en la base de datos tienes una tabla llamada dogs con cuatro registros, pero a diferencia de lo aprendido en el pasado, no hemos configurado la tabla en la que queríamos registrar a nuestro caninos, sin embargo ahí están, ¿como ha sido posible? pues ahora lo veremos.

Una de las ventajas de crear nuestros archivos de la manera que lo hicimos es que, con solo darle un nombre a nuestro modelo y pasarle los flags correspondiente, Laravel toma ese nombre y lo maneja según las convenciones ya establecidas dentro del marco, para de esta manera configurar las relaciones entre cada uno de ellos sin que nosotros tengamos que hacer nada más.

Puedes aprender más sobre como usarlos flags en la creación de modelos en el siguiente enlace: Modelos laravel)

Un ejemplo simple: cuando creamos el modelo llamado Dog, Eloquent asumirá que el nombre de la tabla será "dogs" y su clave principal es "id", por lo que lo configurará de esta manera sin que tengamos que decirle nada, de igual manera procederá a crear los archivos correspondiente a los flags que le enviemos anteponiendo el nombre del modelo, entre otras configuración según el caso (ej. En los model factories verás como agrega el modelo explícitamente como una propiedad de la clase).

Models Factories

Anteriormente habíamos insertado algunos registro mediante nuestro seeder, de una forma muy fácil y agradable si sólo se necesitan unos pocos, sin embargo quedamos con la duda de ¿qué pasa con los momentos en que necesita cargar hasta 100 perros? ¿Puedes pensar en 100 nombres de perros?. Obviamente esto seria una tarea bastante larga y tediosa, y no hablemos de lo mal que queda frente a las buenas prácticas, esto agrandaría nuestro código y estaríamos repitiendo nuestras instrucciones cientos de veces. Podríamos pensar en la implementación de un bucle con la intención de reutilizar nuestra sentencia de creación, esto nos ahorraría muchas lineas de código, sin embargo, no nos quita el problema de los nombres de nuestros amigos caninos, quienes pasarían a llamarse "Qswdcg" o algo por el estilo, por lo que necesitamos una solución que sea más eficiente y consistente, esta solución son los Model factories.

A partir de la última versión de Laravel (v8.0), la forma de trabajar de las factories ha cambiado, así que toma en cuenta que lo que te explicaré acá no será compatible con versiones anteriores, a menos que hagas las respectivas adaptaciones. Si quieres saber mas sobre que cambió puedes revisar el siguiente link: Actualizar model factories.

Los models factories son clases php con la responsabilidad de crear instancias de nuestro objetos con información ya precargada según la configuración que le demos. La verdad son bastante potentes y en esta ultima versión le han sido añadido un gran cantidad de recursos bastante útiles que agilizan y facilitan el desarrollo de nuestras aplicaciones.

Vayamos a nuestro directorio database/factories/, y encontraremos un archivo llamado DogFactory. Echemos un vistazo:

    class DogFactory extends Factory
    {
        /**
        * The name of the factory's corresponding model.
        *
        * @var string
        */
        protected $model = Dog::class;

        /**
        * Define the model's default state.
        *
        * @return array
        */
        public function definition()
        {
            return [
                //
            ];
        }
    }

Vemos que nuestra clase solo tiene una propiedad y un método. La propiedad model tiene asignada el modelo con el cual se relaciona, como hemos creado nuestro modelo con el flag correspondiente (-f), esta asignación la hace Laravel por defecto, de no haberla pasado deberíamos hacerlo nosotros manualmente. Con respecto al método definition, este retorna un array el cual contendrá un par clave-valor, siendo la clave el nombre de nuestros campos asignados en la base de datos, y el valor puede ser lo que queramos que contenga nuestro modelo en dicho atributo cuando creamos una instancia a través de este factory.


    public function definition()
    {
        return [
            'name'=> 'Jackie'
        ];
    }

En el ejemplo que acabo de colocar es necesario hacer varias aclaratorias:

Solo he colocado name pues es el único campo que hemos agregado en nuestra migración, a pesar de que en nuestra base de datos existen un par de campos más (created_at y updated_at), no es necesarios que los agregue acá puesto que eloquent se encarga de gestionarlos automáticamente.
Aunque he añadido una cadena, eso no impedirá que cuando ejecute el seeder, los nombres que yo haya asignado cuando creo una instancia de Dog mediante factory (ver fig. 1) sean asignado.
(ej. Puedo ejecutar Dog::factory()->create(['name' => 'Jock']); y el registro se guardará como Jock y no como Jackie, pues estoy sobrescribiendo la configuración dada.
Si! seguimos teniendo el problema de crear muchos registros, puesto que todos se llamarán Jackie, pero no te apresures, fue intencional por motivos ilustrativos.

¿Como podemos hacer entonces para que nuestros amigos tengan todos nombres distintos? Pues aquí entra el segundo elemento de nuestra lista Faker, recurso bastante interesante que nos ayudará a poblar nuestra base de datos de una manera consistente y dinámica.

Faker

Faker es una biblioteca maravillosa que nos dará datos falsos pero realistas que podremos sembrar.

Hagamos una fábrica para perros y luego veamos cómo usarla en nuestro seeder:

    public function definition()
    {
        return [
            'name'=> $this->faker->firstName
        ];
    }

y ahora en nuestro seeder:

    public function run()
    {
        Dog::factory()->count(10)->create();
    }

Acá le estamos indicando a nuestro seeder que pueble nuestra base de datos con 10 registros, por lo que procederá a registrar 10 perros en nuestra tabla dogs, verás como cada uno tiene su propio nombre, y además ese nombre es perfectamente legible y pronunciable (si, se que siguen siendo algunos nombre raros para unos perros...bueno todos, pero es mejor que llamarlos “Jsdhak”).

Puedes migrar y sembrar las veces que quieras (recuerda las buenas prácticas que hemos aprendido) y jugar con la cantidad de registros, notarás como siempre los nombres son distintos para cada uno de tus caninos.

Hay un último consejo que aprender antes de terminar por hoy que nos ahorrará tener que recordar y escribir todo ese comando cuando sembramos nuestros registros de perros. Hasta ahora siempre hemos ejecutado nuestro comando sembrador pasando el nombre del seeder a ejecutar, esto lo podemos cambiar si hacemos una pequeña configuración que nos facilitará aun más las cosas.

Vamos al directorio database/seeds/ y abrimos el archivo DatabaseSeeder.php, esta es de alguna forma una clase madre en la que podemos llamar de manera individual todos y cada uno de nuestro seeders, por ahora solo tenemos uno, pero cuando nos toque trabajar con aplicaciones más grandes, agradeceremos por la existencia de este gran elemento.

Como ya hemos abierto el archivo, procedamos entonces a agregar nuestro DogSeeder para que su clase madre, al ser llamada, ejecute todo lo que en ella este contenida:

    public function run()
    {
        $this->call(DogsTableSeeder::class);
    }

El método run debe verse como en el código anterior, con esto ya hemos añadido nuestro seeder, de ahora en adelante, cada vez que queramos que nuestros seeders se ejecuten por lote, los agregaremos acá,y eso será todo, podremos recrear toda nuestra base de datos con datos de semillas con un comando simple:

    php artisan migrate:refresh --seed

Hasta ahora llevamos dos lección y todavía apenas hemos tocado Eloquent!. No te preocupes que eso va a cambiar a partir de la próxima entrega, pero era necesario aprender lo que hasta ahora hemos visto, pues nos facilitará enormemente la vida ayudándonos a crear un entorno de desarrollo de forma rápida y sencilla ahorrándonos mucho tiempo y frustración a medida que creamos nuestro proyecto.

Puedes ampliar mucho mas revisando la documentación oficial de Laravel, te invito a que de verdad le des una ojeada, pues facilitará mucho tu curva de aprendizaje.

Quédate atento a la próxima entrega, si tienes alguna duda puedes contactarme en mi cuenta de Twitter @johantovar o déjala en los comentarios. Hasta entonces y que tengas un feliz y exitoso día.

Aprende eloquent con ejemplos!!!

Johan Tovar — Sun, 11 Apr 2021 20:52:46 +0000

Una serie de artículos basados e inspirados en el curso EloquentbyExample del desarrollador Jeff Madsen(@codebyjeff ), dirigidos a ilustrar el uso de eloquent, famoso ORM usado por laravel para la interacción con bases de datos.

Bienvenidos a este nuevo proyecto que inicio con muchas ganas y entusiasmo, siempre he querido retribuir de alguna manera el conocimiento que he adquirido en la red, a través de publicaciones, cursos, tutoriales y un sin fin de material que, con el ánimo solo de compartir, transmitir y nutrir a la comunidad de desarrolladores, muchos de sus integrantes han elaborado de manera desinteresada, por lo que me siento orgulloso hoy día de unirme a ellos con este pequeño pero importante aporte.

Antes de entrar de lleno con el contenido que pretendo desarrollar a lo largo de esta serie de publicaciones, quiero dar un agradecimiento y un reconocimiento a Jeff Madsen, por haberme permitido tomar su curso EloquentbyExample como base para la elaboración del contenido de este proyecto, pues fue este curso el detonante que necesité para atreverme a dar este paso. Gracias Jeff!!!

Pues bien, hechos los respectivos agradecimientos y las aclaraciones pertinentes, entremos en materia y demos comienzo a este pequeño curso.

Empecemos por dar un poco de contexto, diciendo que tenemos una aplicación para un centro veterinario en el que necesitamos registrar todos los caninos que ingresan, para esto, nuestro jefe nos ha indicado agregar un módulo "dogs" (aunque el curso es una adaptación al español, es mejor mantener las buenas prácticas de codificar en inglés), por lo que tendremos que configurar la base de datos y dejar todo listo para lo que se construirá más adelante. Debemos comenzar por crear la tabla de una manera que se pueda agregar fácilmente a los servidores locales y compartidos de los otros desarrolladores, así como al modelo eloquent.

Nota: Laravel viene con una configuración para la base de datos ya predefinida que no debería darte problemas, sin embargo te dejo el enlace por si necesitas hacer alguna configuración adicional Database: Getting Started - Laravel.

Migraciones:

El primer paso que debemos dar en laravel para crear nuestra tabla es crear una migración, para lo cual ejecutaremos un simple comando en nuestra consola:

php artisan make:migration create_dogs_table
~~~

Simple ¿verdad?. Este sencillo comando nos genera un archivo en la ruta */database/migrations*, si vamos ahí encontraremos un total de cuatro archivos, tres de ellos ya vienen con laravel por defecto, el cuarto es el archivo que hemos creado.

![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c2oh1j6392tfrpstqvfq.png)

Así de fácil hemos creado nuestra primera migración, pasemos ahora a abrir el archivo, veremos que en realidad trae muy poco, apenas un par de funciones, `up()` y `down()`, totalmente vacías, y si revisamos nuestra base de datos, no tenemos nada!!!

Hasta ahora lo único que hemos hecho es crear un archivo de “andamiaje básico” para contener la información que se convertirá en una declaración `CREATE TABLE`, con un comando separado pero similar, llamado `migrate`. Ahora bien, cuando los desarrolladores comenzamos a trabajar con migraciones, no tenemos una noción clara sobre estas diferencias, por lo que terminamos "arreglando" un montón de cosas manualmente, haciendo un total desastre.

Es importante que tengamos claro que este archivo mantendrá nuestra información de creación de tablas, por lo que podemos hacer los cambios que queramos, incluso borrarlos, sin consecuencias, mientras no ejecutemos el comando real `php artisan migrate`, encargado de recorrer todos los archivos *migrations* y crear así nuestras tablas.

Entendido lo anterior, vamos ahora a crear nuestra migración como es debido, así que, eliminemos el archivo para que podamos hacer una mejor versión y ejecutemos el siguiente comando:



```php
php artisan make:migration create_dogs_table --create=dogs

Si te fijas hemos agregado --create=dogs, ahora en nuestro archivo, encontraremos que se han agregado algunas líneas más de código, aportan utilidad a las funciones up() y down(). En la primera de estas creamos nuestra tabla, con la segunda revertimos la instrucción anterior. Agreguemos entonces un campo a nuestra migración, de tal manera que nuestro archivo se verá así:

public function up()
{
    Schema::create('dogs', function (Blueprint $table) {
        $table->id();
        $table->string(‘name’);
        $table->timestamps();
    });
}

public function down()
{
    Schema::dropIfExists('dogs');
}

Ejecutemos ahora el comando php artisan migrate, y busquemos ahora en nuestra base de datos, encontraremos que se han creado las tablas correspondientes.

Hasta ahora no hemos ahondado en el tema de las migraciones, pues el desarrollo completo de este particular escapa del ámbito de lo que se pretende plasmar en el curso, pero si quieres profundizar más sobre el tema te invito a revisar la documentación de laravel, quizás en otra oportunidad haga una serie dedicada solo al tema de las migraciones, pero, por lo pronto, quedémonos con lo explicado y veamos algunas cosas importantes antes de pasar a la siguiente tarea.

Borrar el archivo migration no afecta nuestra tabla de manera directa, por ende, no implica que se borre nuestra tabla.
Al crear el archivo migration puedes asignarle cualquier nombre al flag --create, pero es una convención establecida (y recomendada) que se escriba en minúscula y en plural (salvo algunas excepciones como tablas pivote).
Se recomienda el uso de php artisan migrate:rollback si necesitas devolver una ejecución previa de migrate. También puedes usar php artisan migrate:refresh para reiniciar tu base de datos.

Seeders

Pasemos ahora a nuestra siguiente tarea, necesitamos trabajar con datos limpios y sin duplicados, pues esto facilitará, entre otros aspectos, a la detección de errores.

La respuesta a esto es Seeders - un conjunto especial de clases que nos permiten rellenar nuestra base de datos una y otra vez con los mismos datos exactos.

Vamos a aprender en la próxima entrega cómo hacer algunos sembradores realmente poderosos para producir grandes datos de desarrollo y pruebas, pero hoy ya se está haciendo un poco largo, así que vamos a presentar la idea. Un "Seeders" es simplemente una clase que rellena la base de datos con su información respectiva. Lo bueno de ellos es que puedes usar una instrucción de línea de comandos simple para actualizar los datos, por lo que después de haber estado trabajando durante un tiempo puedes limpiarlo y empezar de nuevo. También te permite evitar nombres como "assdffggggg" y otros datos sucios que pueden causar algún bug.

Vayamos a la línea de comandos y escribamos:

php artisan make:seeder DogsTableSeeder

Este comando creará un archivo en /database/seeders, vamos ahí y abramos el archivo, veremos una clase muy simple con un único método llamado run(). No hay nada mágico en esta clase, es realmente poco más que un envoltorio alrededor de una clase de comando de consola, hecho específicamente para ayudar con esta tarea en particular. Vamos a comprobarlo nosotros mismos añadiendo lo siguiente:

public function run()
{
    echo 'Sembrando datos!';
}

y luego de vuelta a la línea de comandos:

php artisan db:seed --class=DogsTableSeeder

Está llamando desde la facade DB, pero no hay ninguna interacción real de la base de datos aquí. Vamos a poblar la tabla ahora con un par de perros:

public function run()
    {
        DB::table('dogs')->insert(['name' => 'Joe']);
        DB::table('dogs')->insert(['name' => 'Jock']);
        DB::table('dogs')->insert(['name' => 'Jackie']);
        DB::table('dogs')->insert(['name' => 'Jane']);
    }

Ahora ejecutemos de nuevo php artisan db:seed --class=DogsTableSeeder, verás que nuestra tabla tendrá cuatro caninos dentro de sus registros.

Si nos fijamos bien, trabajando de esta manera podremos eliminar, agregar y/o editar nuestros perros mientras trabajamos, y luego con un simple comando restablecerlos a un estado inicial, sin embargo, hay algunas mejoras que podemos hacerle a este código, una de ellas es que, de la forma que lo hemos planteado, debemos ser nosotros quienes elegimos los nombres, algo que se hace fácil si solo son unos pocos registros, pero, si nos toca hacerlo con unos 500 perros la tarea no se hace tan divertida ¿cierto?.

Por otra parte imaginemos ¿qué pasaría si tenemos otra lógica que queremos que suceda en el tiempo de creación del registro de perros?. Aquí estamos insertando directamente el nombre en la tabla, pero realmente queremos usar el ORM eloquent que viene con Laravel, al fin y al cabo es lo que vinimos a aprender, pues bien, en la próxima entrega veremos ésta y otras mejoras que de seguro harán nuestro trabajo más fácil, por ahora te invito a que le eches un ojo a la documentación oficial sobre los seeders.

Quédate atento a la próxima entrega, si tienes alguna duda puedes contactarme en mi cuenta de twitter @JohanTovar o déjala en los comentarios. Hasta entonces y que tengas un feliz y exitoso día.