Ya estoy inscrito ¿Todavía no tienes acceso? Nuestros Planes
Ya estoy inscrito ¿Todavía no tienes acceso? Nuestros Planes
2
respuestas

[Duda] Duda acerca de la congruencia en las condiciones a la hora de recibir datos

Pregunto, hay alguna razón en específico para que el profesor NO defina las columnas "complemento" y "numero" como not null pero a la hora de implementar las validaciones sí indique que deben ser not null con la anotación @NotBlank de Validations? Adjunto imágenes un poco más explicativas:

El profesor está especificando desde el DTO que ninguno de los atributos de la dirección debe llegar en blanco ni nulo, tal como se ve en la imagen:

Imagen de DatosDireccion Código en caso de que la imagen no se logre visualizar:

package med.voll.vollapirest.direccion;

import jakarta.validation.constraints.NotBlank;

public record DatosDireccion(

        @NotBlank
        String calle,

        @NotBlank
        String distrito,

        @NotBlank
        String ciudad,
        
        @NotBlank
        String numero,
        
        @NotBlank
        String complemento
) {
}

Sin embargo, al crear la tabla médicos por medio de la migración de Flyway, él definió las columnas "numero" y "complemento" de la siguiente manera:

Imagen migración FlywayLa sentencia en caso de que la imagen no se logre visualizar:

CREATE TABLE medicos (
                         id BIGINT NOT NULL AUTO_INCREMENT,
                         nombre VARCHAR(100) NOT NULL,
                         email VARCHAR(100) NOT NULL UNIQUE,
                         documento VARCHAR(6) NOT NULL UNIQUE,
                         especialidad VARCHAR(100) NOT NULL,
                         calle VARCHAR(100) NOT NULL,
                         distrito VARCHAR(100) NOT NULL,
                         complemento VARCHAR(100),
                         numero VARCHAR(20),
                         ciudad VARCHAR(100) NOT NULL,
                         PRIMARY KEY (id)
);

Mi sentido más lógico sugiere que no tendría sentido el hecho de indicar a la BD que esas dos columnas pueden contener datos nulos teniendo en cuenta que desde que se recibe la request se implementa la condición de que no deben estar nulos por medio del módulo Validations, además de que el profesor en una ocasión dijo verbalmente que estos campos no deberían tener la restricción "not null" debido a que es posible que no haya número ni complemento en alguna dirección.

Yo diría que simplemente fue un error del profesor. Sin embargo, me gustaría saber si hay alguna razón en específico detrás ya que de todas formas soy nuevo en lo que estamos viendo. Agradezco cualquier respuesta.

PD: En el minuto 1:50 de la clase "Validación" hay un error en la edición, donde el profesor deja ver unas pestañas que no deseaba y repite dos veces lo que estaba diciendo con ánimo de recortar esa parte. Ese recorte al parecer se pasó por alto el realizarlo durante la edición y quedó grabado el fragmento completo en donde comete esa pequeña equivocación. Obviamente no es algo muy relevante ni entorpece el aprendizaje, pero ya que sé que la mayoría de las veces los integrantes del Alura Team ven los temas del foro, no pierdo nada con mencionarlo si es que se quiere corregir dicho error de edición.

2 respuestas

¡Hola Julián, espero que estés bien!

Entiendo tu confusión con respecto a la definición de las columnas "numero" y "complemento" en la base de datos y la implementación de las validaciones en el DTO. Aunque puede parecer contradictorio, en realidad hay una razón específica para esta configuración.

La razón por la que el profesor definió las columnas "numero" y "complemento" de la tabla "medicos" permitiendo valores nulos, a pesar de implementar validaciones de no nulidad en el DTO, es para manejar casos en los que no haya número ni complemento en alguna dirección. Esto puede ocurrir en situaciones reales, y al permitir valores nulos en la base de datos, se brinda flexibilidad para manejar estos escenarios.

Por ejemplo, si se requiere almacenar una dirección que no tenga un número o un complemento, la base de datos permitirá valores nulos en esas columnas, mientras que las validaciones en el DTO garantizarán que, si se proporciona un número o un complemento, no estén en blanco ni nulos.

En resumen, la combinación de la configuración de la base de datos y las validaciones en el DTO permite adaptarse a diferentes escenarios del mundo real, brindando flexibilidad sin comprometer la integridad de los datos.

Espero que esta explicación aclare tus dudas. ¡Sigue adelante con tu aprendizaje en Spring Boot!

Espero haber ayudado y buenos estudios!

Brenda pero sigo sin entender. Para qué pondría en la BD que se admiten valores nulos (precisamente para manejar el caso de que una dirección no tenga número o complemento) cuando nunca va a llegar ningún dato nulo a la BD, dado que en las validaciones del DTO no permitirán que se ingresen datos nulos en estos campos?

O sea, el único caso donde esto tendría sentido es que la tabla "medicos" no solo se alimente de los datos que pasan por el DTO, pero eso no me lo has especificado entonces sigo teniendo la misma duda. O sea es como si, en un ejemplo hipotético, yo en la fiesta de mi casa dejo entrar a niños con el objetivo de que haya más diversidad de personas, pero en la portería de mi edificio solamente dejan entrar adultos y no niños. De nada serviría el hecho de que yo deje entrar a niños cuando nunca van a llegar dado que se están filtrando desde la portería.

Pasa lo mismo acá, permito que hayan datos nulos en dos columnas de mi BD pero el DTO que me proporciona los datos no permite que hayan datos nulos en los atributos correspondientes, así que de nada sirve que yo permita datos nulos en mi BD porque nunca van a llegar nulos.