Luego otra pregunta de Romeo, ¿cómo sabremos si la relación es de muchos a muchos o de uno a muchos? Esto se puede ver directamente dentro del esquema de Prisma, ¿verdad? Porque dentro del esquema de Prisma, se declara si un campo es una lista o no. Entonces, en este caso, en un lado, declaré que hay una lista. Y en el otro lado, declaré que no hay una lista, sino solo un campo o una entrada única. Y por eso podemos saber que es de uno a muchos. Si quisiéramos hacer esto de muchos a muchos, donde un post podría tener varios autores, lo cual sería un caso de uso válido, supongo, podría hacer esto. Y en este caso, tendríamos una relación de muchos a muchos donde ya no almacenaríamos un ID de autor porque Prisma, bajo el capó, crearía una tabla de relación o una tabla de unión para realizar un seguimiento de todos los registros relacionados.
Otra pregunta sobre la bandera de nombre en el comando Prisma Migrate dev. Entonces, la bandera de nombre es responsable de nombrar la migración. Por lo tanto, es lo que se agrega a los directorios de migración que se crean en tu sistema de archivos cuando proporcionas este valor.
La siguiente pregunta es si el autocompletado es la única mejor manera de ver todos los parámetros de consulta disponibles. Si me preguntas, sí, es la mejor manera. Pero no es la única manera. También tenemos una extensa documentación de API para Prisma. Entonces, si vas a nuestra documentación y consultas la referencia de la API de Prisma Client, puedes ver las consultas de modelo para cada tipo de consulta, ya sea para encontrar único o las opciones que se proporcionan para obtener información sobre el tipo de retorno. Así que tenemos una documentación muy completa que enumera todo lo que puedes hacer con todas estas consultas.
Vamos a ver. Más preguntas, una pregunta más de Christian. Digamos que tengo un proyecto de sjs y usa Mongoose. Estoy pensando en cambiarlo en algún momento en el futuro para usar Postgres. ¿Puedo implementar Prisma en mi proyecto? Estoy usando MongoDB. Tal vez cuando llegue el momento, simplemente cambiaré la fuente de datos a Postgres desde el esquema de Prisma. Esa es una muy buena pregunta. Entonces, la pregunta básicamente es si Prisma, si el esquema de Prisma abstrae las fuentes de datos de tal manera que siempre puedes cambiar la base de datos subyacente y seguir trabajando con el mismo esquema. Si entiendo correctamente tu pregunta, creo que esa es su pregunta, de lo contrario, siéntete libre de corregirme. La respuesta a esto es no, no puedes hacer esto. Y en realidad, hay una muy buena razón. Creo que por qué no es posible y por qué no es el caso. El esquema de Prisma no está destinado a ser una abstracción de base de datos única para todos los casos. Reconocemos que cada base de datos y cada tipo de base de datos tiene sus propias fortalezas y debilidades, con sus propias características. Y queremos asegurarnos de que admitamos todas las características de una base de datos cuando construimos un conector de Prisma para ella. Y específicamente, como ejemplo, por qué esto no es posible, si miramos SQLite, por ejemplo, que es una base de datos bastante sencilla en términos de los tipos de datos que admite. Y por ejemplo, en SQLite, no se admite el uso de enumeraciones. Pero las enumeraciones son una parte crucial del modelado de datos cuando trabajas con Postgres o MySQL. En estos otros bases de datos, se admiten las enumeraciones. Eso significa que ahora aquí en mi esquema de Prisma de SQLite, no puedo definir una enumeración, pero si lo cambiara a Postgres donde se admiten, podría usar una enumeración aquí. Pero si cambio esto nuevamente a SQLite, no es posible. Tratamos de asegurarnos de que sin importar qué base de datos uses, puedas aprovechar todas las características subyacentes de la base de datos. Y en tu ejemplo, específicamente Christian, donde estás pensando en cambiar de MongoDB a una base de datos relacional, esto también es mucho más complicado que, por supuesto, en términos de cómo modelaste tus datos en primer lugar en MongoDB. Si estás usando, por ejemplo, muchos documentos incrustados, no hay realmente una buena manera de representarlos en una base de datos relacional. Supongo que en Postgres podrías usar la columna JSON, por lo que esa podría ser una forma de migrar los datos. Pero en general, no es un caso de uso, al menos para el que estamos optimizando, pero si tu esquema de Prisma solo usa características bastante sencillas que también se encuentran en todas las demás bases de datos, supongo que es posible, pero no es realmente un caso de uso para el que estamos optimizando. ¿Hay alguna manera de generar modelos a partir de una base de datos existente como SQLite auto para SQLite? No estoy familiarizado con SQLite auto, pero creo que si entiendo correctamente tu pregunta, sí, hay una forma de hacerlo, lo llamamos introspección. Y básicamente es un comando en la CLI de Prisma, se llama Prisma DB pull que ejecuta la introspección. Y si lo ejecutas contra una base de datos, leerá el esquema de la base de datos. Por lo tanto, examinará las tablas, examinará las columnas y completará el esquema de Prisma para que no tengas que escribir los modelos de Prisma a mano si ya tienes una base de datos existente. Sí, genial. Sí, es muy útil, el comando Prisma DB pull. De hecho, esto también es algo que estamos construyendo actualmente incluso para MongoDB para facilitar que los usuarios actuales de Mongo comiencen. Y, por supuesto, con MongoDB, es un poco más complicado porque en realidad no tienes un esquema, ¿verdad? No es algo que haga cumplir la base de datos en sí. Así que esperamos que los datos que las personas hayan puesto en sus MongoDB sean consistentes. Y luego lo leemos y derivamos las estructuras de modelo de los objetos individuales que las personas tienen en sus bases de datos.
Comments