Cuando trabajas con una API sin validaciones, cualquier campo puede colarse en tu base de datos: nombres diferentes para el mismo dato, tipos incorrectos o registros incompletos. Definir un modelo con tipos, campos requeridos y restricciones de longitud es la solución para mantener la consistencia y evitar problemas a largo plazo en tu aplicación.

¿Por qué es importante validar los campos de un modelo?

Sin validaciones, al crear registros desde Postman o cualquier cliente, nada impide enviar un campo llamado name en un request y title en otro [0:20]. Ambos se guardan sin error, pero cuando la aplicación necesita leer esos datos, debe adivinar si el campo se llama name o title, qué formato tiene la fecha o cuántos campos existen. Esto genera un desorden difícil de mantener.

Sails.js permite resolver esto mediante la definición de atributos primitivos dentro del modelo. Los primitivos son campos que no tienen relación con otras entidades, como el título o la fecha de inicio de una rodada [1:40].

¿Cómo se define la estructura del modelo Raid en Sails?

Dentro del archivo de modelo Raid, se reemplazan los comentarios por la definición de cada atributo. Cada campo es un objeto de JavaScript con propiedades que determinan su comportamiento [2:00].

¿Qué atributos componen el modelo?

• title: de tipo string, con required: true, minLength: 5 y maxLength: 50. Así se garantiza que el título no sea demasiado corto ni excesivamente largo [2:10].
• start: de tipo string, también requerido. Representa la fecha de inicio y se parsea en el cliente para mostrarla como fecha [2:55].
• end: de tipo string, pero no requerido. Como la fecha de fin suele ser calculada, exigirla desde la creación provocaría errores innecesarios [3:10].
• waypoints: de tipo json, no requerido. Almacena un arreglo de objetos con los puntos intermedios de una ruta, por ejemplo, paradas entre Monterrey y Bogotá [3:30].

El concepto de required establece que un campo es obligatorio al crear un registro. Si no se envía, la API devuelve un error de validación. Por otro lado, minLength y maxLength son restricciones de longitud que controlan cuántos caracteres acepta un string [2:25].

¿Qué ocurre con los valores por defecto?

Los campos no requeridos reciben un valor por defecto automático. Un string queda como cadena vacía (""), mientras que un campo de tipo json se inicializa como null [5:05]. Esto significa que siempre aparecen en el objeto devuelto, aunque el usuario no los haya enviado.

¿Cómo resolver errores de migración al cambiar el modelo?

Al guardar el modelo actualizado y levantar el servidor, puede aparecer un error de auto migrations [4:15]. Esto sucede cuando ya existen registros en la base de datos que no cumplen con las nuevas restricciones, por ejemplo, un registro con name cuando el modelo ahora solo acepta title.

La solución es cambiar la estrategia de migración. En lugar de usar alter, se utiliza drop al levantar Sails:

bash sails lift --drop

Esto elimina todos los datos existentes y recrea las colecciones con la nueva estructura [4:40]. Es una operación destructiva, ideal solo en desarrollo.

Una vez levantado con drop, el GET devuelve un arreglo vacío porque la base de datos se limpió. Al crear un nuevo registro con title, todo funciona correctamente. Si se intenta enviar name en lugar de title, la API responde con un error de validación indicando que el campo es inválido [4:55].

Definir modelos específicos con sus tipos de dato, campos obligatorios y restricciones de longitud simplifica enormemente el trabajo al crear y consultar registros. ¿Has tenido problemas de inconsistencia en tu base de datos por falta de validaciones? Comparte tu experiencia.