Migrate from Sequelize
This guide describes how to migrate from Sequelize to Prisma ORM. It uses an extended version of the Sequelize Express example as a sample project to demonstrate the migration steps. You can find the example used for this guide on GitHub.
This migration guide uses PostgreSQL as the example database, but it equally applies to any other relational database that's supported by Prisma.
You can learn how Prisma ORM compares to Sequelize on the Prisma ORM vs Sequelize page.
Overview of the migration process
Note that the steps for migrating from Sequelize to Prisma ORM are always the same, no matter what kind of application or API layer you're building:
- Install the Prisma CLI
- Introspect your database
- Create a baseline migration
- Install Prisma Client
- Gradually replace your Sequelize queries with Prisma Client
These steps apply, no matter if you're building a REST API (e.g. with Express, koa or NestJS), a GraphQL API (e.g. with Apollo Server, TypeGraphQL or Nexus) or any other kind of application that uses Sequelize for database access.
Prisma ORM lends itself really well for incremental adoption. This means, you don't have migrate your entire project from Sequelize to Prisma ORM at once, but rather you can step-by-step move your database queries from Sequelize to Prisma ORM.
Overview of the sample project
For this guide, we'll use a REST API built with Express as a sample project to migrate to Prisma ORM. It has four models/entities:
- User.js
- Post.js
- Profile.js
- Category.js
module.exports = (sequelize, DataTypes) => {
const User = sequelize.define('User', {
name: {
type: DataTypes.STRING,
},
email: {
type: DataTypes.STRING,
unique: true,
allowNull: false,
},
})
User.associate = (models) => {
User.hasMany(models.Post, {
foreignKey: 'authorId',
as: 'posts',
})
User.hasOne(models.Profile, {
onDelete: 'CASCADE',
foreignKey: 'userId',
})
}
return User
}
module.exports = (sequelize, DataTypes) => {
const Post = sequelize.define('Post', {
title: {
type: DataTypes.STRING,
allowNull: false,
},
content: {
type: DataTypes.STRING,
},
published: {
type: DataTypes.BOOLEAN,
defaultValue: false,
},
})
Post.associate = (models) => {
Post.belongsTo(models.User, {
foreignKey: 'authorId',
as: 'author',
})
Post.belongsToMany(models.Category, {
through: 'PostCategories',
as: 'categories',
})
}
return Post
}
module.exports = (sequelize, DataTypes) => {
const Profile = sequelize.define('Profile', {
bio: {
type: DataTypes.STRING,
allowNull: false,
},
})
Profile.associate = (models) => {
Profile.belongsTo(models.User, {
foreignKey: 'userId',
as: 'user',
})
}
return Profile
}
module.exports = (sequelize, DataTypes) => {
const Category = sequelize.define('Category', {
name: {
type: DataTypes.STRING,
allowNull: false,
},
})
Category.associate = (models) => {
Category.belongsToMany(models.Post, {
through: 'PostCategories',
as: 'posts',
})
}
return Category
}
The models have the following relations:
- 1-1:
User
↔Profile
- 1-n:
User
↔Post
- m-n:
Post
↔Category
The corresponding tables have been created using a generated Sequelize migration.
In this guide, the route handlers are located in the src/controllers
directory. The models are located in the src/models
directory. From there, they are pulled into a central src/routes.js
file which is used to set up the required routes in src/index.js
:
└── blog-sequelize
├── package.json
└──src
├── controllers
│ ├── post.js
│ └── user.js
├── models
│ ├── Category.js
│ ├── Post.js
│ ├── Profile.js
│ └── User.js
├── index.js
└── routes.js
Step 1. Install the Prisma CLI
The first step to adopt Prisma ORM is to install the Prisma CLI in your project:
npm install prisma --save-dev
Step 2. Introspect your database
2.1. Set up Prisma ORM
Before you can introspect your database, you need to set up your Prisma schema and connect Prisma ORM to your database. Run the following command in your terminal to create a basic Prisma schema file:
npx prisma init
This command created a new directory called prisma
with the following files for you:
schema.prisma
: Your Prisma schema that specifies your database connection and models.env
: Adotenv
to configure your database connection URL as an environment variable
The Prisma schema currently looks as follows:
// This is your Prisma schema file,
// learn more about it in the docs: https://pris.ly/d/prisma-schema
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}
generator client {
provider = "prisma-client-js"
}
If you're using VS Code, be sure to install the Prisma VS Code extension for syntax highlighting, formatting, auto-completion and a lot more cool features.
2.2. Connect your database
If you're not using PostgreSQL, you need to adjust the provider
field on the datasource
block to the database you currently use:
- PostgreSQL
- MySQL
- Microsoft SQL Server
- SQLite
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}
datasource db {
provider = "mysql"
url = env("DATABASE_URL")
}
datasource db {
provider = "sqlserver"
url = env("DATABASE_URL")
}
datasource db {
provider = "sqlite"
url = env("DATABASE_URL")
}
Once that's done, you can configure your database connection URL in the .env
file. Here's how the database connection from Sequelize maps to the connection URL format used by Prisma ORM:
- PostgreSQL
- MySQL
- Microsoft SQL Server
- SQLite
Assume you have the following database connection details in src/models/index.js
:
const sequelize = new Sequelize('blog-sequelize', 'alice', 'myPassword42', {
host: 'localhost',
dialect: 'postgres',
})
The respective connection URL would look as follows in Prisma ORM:
DATABASE_URL="postgresql://alice:myPassword42@localhost:5432/blog-sequelize"
Note that you can optionally configure the PostgreSQL schema by appending the schema
argument to the connection URL:
DATABASE_URL="postgresql://alice:myPassword42@localhost:5432/blog-sequelize?schema=myschema"
If not provided, the default schema called public
is being used.
Assume you have the following database connection details in src/models/index.js
:
const sequelize = new Sequelize('blog-sequelize', 'alice', 'myPassword42', {
host: 'localhost',
dialect: 'postgres',
})
The respective connection URL would look as follows in Prisma:
DATABASE_URL="mysql://alice:myPassword42@localhost:3306/blog-sequelize"
Assume you have the following database connection details in src/models/index.js
:
const sequelize = new Sequelize('blog-sequelize', 'alice', 'myPassword42', {
host: 'localhost',
dialect: 'mssql',
})
The respective connection URL would look as follows in Prisma:
DATABASE_URL="sqlserver://localhost:1433;database=blog-sequelize;user=alice;password=myPassword42;trustServerCertificate=true"
Assume you have the following database connection details in src/models/index.js
:
const sequelize = new Sequelize({
dialect: 'sqlite',
storage: '../../blog-sequelize.sqlite',
})
The respective connection URL would look as follows in Prisma:
DATABASE_URL="file:./blog-sequelize.db"
2.3. Introspect your database using Prisma ORM
With your connection URL in place, you can introspect your database to generate your Prisma models:
npx prisma db pull
This creates the following Prisma models:
model Categories {
id Int @id @default(autoincrement())
name String
createdAt DateTime
updatedAt DateTime
PostCategories PostCategories[]
}
model PostCategories {
createdAt DateTime
updatedAt DateTime
CategoryId Int
PostId Int
Categories Categories @relation(fields: [CategoryId], references: [id])
Posts Posts @relation(fields: [PostId], references: [id])
@@id([CategoryId, PostId])
}
model Posts {
id Int @id @default(autoincrement())
title String
content String?
published Boolean? @default(false)
createdAt DateTime
updatedAt DateTime
authorId Int?
Users Users? @relation(fields: [authorId], references: [id])
PostCategories PostCategories[]
}
model Profiles {
id Int @id @default(autoincrement())
bio String
createdAt DateTime
updatedAt DateTime
userId Int? @unique
Users Users? @relation(fields: [userId], references: [id])
}
model SequelizeMeta {
name String @id
}
model Users {
id Int @id @default(autoincrement())
name String?
email String @unique
createdAt DateTime
updatedAt DateTime
Posts Posts[]
Profiles Profiles?
}
2.4. Create a baseline migration
To continue using Prisma Migrate to evolve your database schema, you will need to baseline your database.
First, create a migrations
directory and add a directory inside with your preferred name for the migration. In this example, we will use 0_init
as the migration name:
mkdir -p prisma/migrations/0_init
Next, generate the migration file with prisma migrate diff
. Use the following arguments:
--from-empty
: assumes the data model you're migrating from is empty--to-schema-datamodel
: the current database state using the URL in thedatasource
block--script
: output a SQL script
npx prisma migrate diff --from-empty --to-schema-datamodel prisma/schema.prisma --script > prisma/migrations/0_init/migration.sql
Review the generated migration to ensure everything is correct.
Next, mark the migration as applied using prisma migrate resolve
with the --applied
argument.
npx prisma migrate resolve --applied 0_init
The command will mark 0_init
as applied by adding it to the _prisma_migrations
table.
You now have a baseline for your current database schema. To make further changes to your database schema, you can update your Prisma schema and use prisma migrate dev
to apply the changes to your database.
2.5. Adjust createdAt
and updatedAt
fields
The generated Prisma models represent your database tables and are the foundation for your programmatic Prisma Client API which allows you to send queries to your database.
You'll adjust the createdAt
and updatedAt
fields in our models. Sequelize doesn't add the DEFAULT
constraint to createdAt
when creating the tables in the database.
Therefore, you'll add @default(now())
and @updatedAt
attributes to the createdAt
and updatedAt
columns respectively.
To learn more how Prisma ORM does this, you can read more @default(now())
and @updatedAt
here.
Our updated schema will be as follows:
model Categories {
id Int @id @default(autoincrement())
name String
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
PostCategories PostCategories[]
}
model PostCategories {
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
CategoryId Int
PostId Int
Categories Categories @relation(fields: [CategoryId], references: [id])
Posts Posts @relation(fields: [PostId], references: [id])
@@id([CategoryId, PostId])
}
model Posts {
id Int @id @default(autoincrement())
title String
content String?
published Boolean? @default(false)
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
authorId Int?
Users Users? @relation(fields: [authorId], references: [id])
PostCategories PostCategories[]
}
model Profiles {
id Int @id @default(autoincrement())
bio String
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
userId Int? @unique
Users Users? @relation(fields: [userId], references: [id])
}
model SequelizeMeta {
name String @id
}
model Users {
id Int @id @default(autoincrement())
name String?
email String @unique
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
Posts Posts[]
Profiles Profiles?
}
2.6. Adjust the Prisma schema (optional)
The models that were generated via introspection currently exactly map to your database tables. In this section, you'll learn how you can adjust the naming of the Prisma models to adhere to Prisma ORM's naming conventions.
All of these adjustment are entirely optional and you are free to skip to the next step already if you don't want to adjust anything for now. You can go back and make the adjustments at any later point.
As opposed to the current snake_case notation of Prisma models, Prisma ORM's naming conventions are:
- PascalCase for model names
- camelCase for field names
You can adjust the naming by mapping the Prisma model and field names to the existing table and column names in the underlying database using @@map
and @map
.
Also note that you can rename relation fields to optimize the Prisma Client API that you'll use later to send queries to your database. For example, although we are singularizing the Posts
model name to Post
, the posts
field on the user
model is a list, so it makes sense to keep that named posts
to indicate that it's plural.
Sequelize generates a SequelizeMeta
model that is used internally by the library that is not needed. Therefore, you'll manually delete it from the schema.
Here's an adjusted version of the Prisma schema that addresses these points:
generator client {
provider = "prisma-client-js"
}
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}
model Category {
id Int @id @default(autoincrement())
name String
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
postCategories PostToCategories[]
@@map("Categories")
}
model PostToCategories {
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
categoryId Int
postId Int
category Category @relation(fields: [categoryId], references: [id])
post Post @relation(fields: [postId], references: [id])
@@id([categoryId, postId])
@@map("PostCategories")
}
model Post {
id Int @id @default(autoincrement())
title String
content String?
published Boolean? @default(false)
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
authorId Int?
author User? @relation(fields: [authorId], references: [id])
postToCategories PostToCategories[]
@@map("Posts")
}
model Profile {
id Int @id @default(autoincrement())
bio String
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
userId Int? @unique
user User? @relation(fields: [userId], references: [id])
@@map("Profiles")
}
model User {
id Int @id @default(autoincrement())
name String?
email String @unique
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
posts Post[]
profile Profile?
@@map("Users")
}
Step 3. Install Prisma Client
As a next step, you can install Prisma Client in your project so that you can start replacing the database queries in your project that are currently made with Sequelize:
npm install @prisma/client
Step 4. Replace your Sequelize queries with Prisma Client
In this section, we'll show a few sample queries that are being migrated from Sequelize to Prisma Client based on the example routes from the sample REST API project. For a comprehensive overview of how the Prisma Client API differs from Sequelize, check out the API comparison page.
First, to set up the PrismaClient
instance that you'll use to send database queries from the various route handlers. Create a new file named prisma.js
in the src
directory:
touch src/prisma.js
Now, instantiate PrismaClient
and export it from the file so you can use it in your route handlers later:
const { PrismaClient } = require('@prisma/client')
const prisma = new PrismaClient()
module.exports = prisma
The imports in our controller files are as follows:
const { Post, User, Category } = require('../models')
const { Op } = require('sequelize')
const { User } = require('../models')
You'll update the controller imports as you migrate from Sequelize to Prisma:
const prisma = require('../prisma')
const prisma = require('../prisma')
4.1. Replacing queries in GET
requests
The REST API has four routes that accept GET
requests:
/feed
: Return all published posts/filterPosts?searchString=SEARCH_STRING
: Filter returned posts bySEARCH_STRING
/post/:postId
: Returns a specific post/authors
: Returns a list of authors
Let's dive into the route handlers that implement these requests.
/feed
The /feed
handler is currently implemented as follows:
const feed = async (req, res) => {
try {
const feed = await Post.findAll({
where: { published: true },
include: ['author', 'categories'],
})
return res.json(feed)
} catch (error) {
return res.status(500).json(error)
}
}
Note that each returned Post
object includes the relation to the author
and category
it's associated with. With Sequelize, including the relation is not type-safe. For example, if there was a typo in the relation that is retrieved, your database query would fail only at runtime – the JavaScript compiler does not provide any safety here.
Here is how the same route is implemented using Prisma Client:
const feed = async (req, res) => {
try {
const feed = await prisma.post.findMany({
where: { published: true },
include: { author: true, postToCategories: true },
})
return res.json(feed)
} catch (error) {
return res.status(500).json(error)
}
}
Note that the way how Prisma Client includes the author
relation is absolutely type-safe. The JavaScript compiler would throw an error if you were trying to include a relation that does not exist on the Post
model.
/filterPosts?searchString=SEARCH_STRING
The /filterPosts
handler is currently implemented as follows:
const filterPosts = async (req, res) => {
const { searchString } = req.query
try {
const filteredPosts = await Post.findAll({
where: {
[Op.or]: [
{
title: {
[Op.like]: `%${searchString}%`,
},
},
{
content: {
[Op.like]: `%${searchString}%`,
},
},
],
},
include: 'author',
})
res.json(filteredPosts)
} catch (error) {
return res.status(500).json(error)
}
}
With Prisma ORM, the route is implemented as follows:
const filterPosts = async (req, res) => {
const { searchString } = req.query
try {
const filteredPosts = prisma.post.findMany({
where: {
OR: [
{
title: { contains: searchString },
},
{
content: { contains: searchString },
},
],
},
})
res.json(filteredPosts)
} catch (error) {
return res.status(500).json(error)
}
}
Note that Sequelize provides Operator symbols - Op
- to be used when querying data. Prisma ORM on the other hand combines several where
conditions with an implicit AND
operator, so in this case the Prisma Client query needs to make the OR
explicit.
/post/:postId
The /post/:postId
handler is currently implemented as follows:
const getPostById = async (req, res) => {
const { postId } = req.params
try {
const post = await Post.findOne({
where: { id: postId },
include: 'author',
})
return res.json(post)
} catch (error) {
return res.status(500).json(error)
}
}
With Prisma ORM, the route is implemented as follows:
const getPostById = async (req, res) => {
const { postId } = req.params
try {
const post = await prisma.post.findUnique({
where: { id: Number(postId) },
include: { author: true },
})
return res.json(post)
} catch (error) {
return res.status(500).json(error)
}
}
4.2. Replacing queries in POST
requests
The REST API has three routes that accept POST
requests:
/user
: Creates a newUser
record/post
: Creates a newUser
record/user/:userId/profile
: Creates a newProfile
record for aUser
record with a given ID
/user
The /user
handler is currently implemented as follows:
const createUser = async (req, res) => {
const { name, email } = req.body
try {
const user = await User.create({
name,
email,
})
return res.json(user)
} catch (error) {
return res.status(500).json(error)
}
}
With Prisma ORM, the route is implemented as follows:
const createUser = async (req, res) => {
const { name, email } = req.body
try {
const user = await prisma.user.create({
data: {
name,
email,
},
})
return res.json(user)
} catch (error) {
return res.status(500).json(error)
}
}
/post
The /post
handler is currently implemented as follows:
const createDraft = async (req, res) => {
const { title, content, authorEmail } = req.body
try {
const user = await User.findOne({ email: authorEmail })
const draft = await Post.create({
title,
content,
authorId: user.id,
})
res.json(draft)
} catch (error) {
return res.status(500).json(error)
}
}
With Prisma ORM, the route is implemented as follows:
const createDraft = async (req, res) => {
const { title, content, authorEmail } = req.body
try {
const draft = await prisma.post.create({
data: {
title,
content,
author: {
connect: { email: authorEmail },
},
},
})
res.json(draft)
} catch (error) {
return res.status(500).json(error)
}
}
Note that Prisma Client's nested write here save an initial query where first the User
record needs to be retrieved by its email
. That's because, with Prisma Client you can connect records in relations using any unique property.
/user/:userId/profile
The /user/:userId/profile
handler is currently implemented as follows:
const setUserBio = async (req, res) => {
const { userId } = req.params
const { bio } = req.body
try {
const user = await User.findOne({
where: {
id: Number(userId),
},
})
const updatedUser = await user.createProfile({ bio })
return res.json(updatedUser)
} catch (error) {
return res.status(500).json(error)
}
}
With Prisma ORM, the route is implemented as follows:
const setUserBio = async (req, res) => {
const { userId } = req.params
const { bio } = req.body
try {
const user = await prisma.user.update({
where: { id: Number(userId) },
data: {
profile: {
create: { bio },
},
},
})
return res.json(user)
} catch (error) {
return res.status(500).json(error)
}
}
4.3. Replacing queries in PUT
requests
The REST API has one route that accept a PUT
request:
/addPostToCategory?postId=POST_ID&categoryId=CATEGORY_ID
: Adds the post withPOST_ID
to the category withCATEGORY_ID
Let's dive into the route handlers that implement these requests.
/addPostToCategory?postId=POST_ID&categoryId=CATEGORY_ID
The /addPostToCategory?postId=POST_ID&categoryId=CATEGORY_ID
handler is currently implemented as follows:
const addPostToCategory = async (req, res) => {
const { postId, categoryId } = req.query
try {
const post = await Post.findOne({
where: { id: postId },
})
const category = await Category.findOne({
where: { id: categoryId },
})
const updatedPost = await post.addCategory(category)
return res.json(updatedPost)
} catch (error) {
return res.status(500).json(error)
}
}
With Prisma ORM, the route is implemented as follows:
const addPostToCategory = async (req, res) => {
const { postId, categoryId } = req.query
try {
const post = await prisma.post.update({
data: {
postToCategories: {
create: {
categories: {
connect: { id: Number(categoryId) },
},
},
},
},
where: {
id: Number(postId),
},
})
return res.json(post)
} catch (error) {
return res.status(500).json(error)
}
}
Note that this Prisma Client can be made less verbose by modeling the relation as an implicit many-to-many relation instead. In that case, the query would look as follows:
const post = await prisma.post.update({
data: {
category: {
connect: { id: categoryId },
},
},
where: { id: postId },
})
More
Primary key column
By default, Sequelize defines a primaryKey
and used id
with the autoby default if not defined. This is optional.
If you would like to set your own primary key, you can use the primaryKey: true
and define your preferred data type in your field of choice:
// changing the primary key column
module.exports = (sequelize, DataTypes) => {
const Post = sequelize.define('Post', {
postId: {
type: DataTypes.INTEGER,
primaryKey: true,
},
})
return Post
}
// changing the id DataType
module.exports = (sequelize, DataTypes) => {
const Post = sequelize.define('Post', {
id: {
type: DataTypes.UUID, // alternative: DataTypes.STRING
primaryKey: true,
},
})
return Post
}
Table name inference
Sequelize infers table names from the model name. When the name of a table isn't provided Sequelize automatically pluralizes the model name and uses that as the table name using a library called inflection. Prisma ORM on the other hand maps the model name to the table name in your database modelling your data. If you wish to change this default behaviour in Sequelize, you can either enforce the table name to be equal to the model name or provide the table name directly:
// enforcing table name to be equal to model name
module.exports = (sequelize, DataTypes) => {
const Post = sequelize.define(
'Post',
{
// ... attributes
},
{
freezeTableName: true,
}
)
return Post
}
// providing the table name directly
module.exports = (sequelize, DataTypes) => {
const Post = sequelize.define(
'Post',
{
// ... attributes
},
{
tableName: 'Post',
}
)
return Post
}
Timestamps
Sequelize automatically adds the fields createdAt
and updatedAt
to every model using the data type DataTypes.DATE
, by default. You can disable this for a model with the timestamps: false
option:
sequelize.define(
'User',
{
// ... (attributes)
},
{
timestamps: false,
}
)
Prisma ORM offers you the flexibility to define these fields in your model. You add the createdAt
and updatedAt
fields by defining them explicitly in your model.
To set the createdAt
field in your model, add the default(now())
attribute to the column. In order to set the updatedAt
column, update your model by adding the @updatedAt
attribute to the column.
model User {
id Int @id @default(autoincrement())
name String?
email String @unique
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
}
Implicit many-to-many relations
Similar to the belongsToMany()
association method in Sequelize, Prisma ORM allows you to model many-to-many relations implicitly. That is, a many-to-many relation where you do not have to manage the relation table (also sometimes called JOIN table) explicitly in your schema. Here is an example with Sequelize:
module.exports = (sequelize, DataTypes) => {
const Post = sequelize.define('Post', {
title: {
type: DataTypes.STRING,
allowNull: false,
},
content: {
type: DataTypes.STRING,
},
published: {
type: DataTypes.BOOLEAN,
defaultValue: false,
},
})
Post.associate = (models) => {
Post.belongsTo(models.User, {
foreignKey: 'authorId',
as: 'author',
})
Post.belongsToMany(models.Category, {
through: 'PostCategories',
as: 'categories',
})
}
return Post
}
module.exports = (sequelize, DataTypes) => {
const Category = sequelize.define('Category', {
name: {
type: DataTypes.STRING,
allowNull: false,
},
})
Category.associate = (models) => {
Category.belongsToMany(models.Post, {
through: 'PostCategories',
as: 'posts',
})
}
return Category
}
When you start your application, Sequelize will create the the tables for you - based on these models:
Executing (default): CREATE TABLE IF NOT EXISTS "PostCategories"
("createdAt" TIMESTAMP WITH TIME ZONE NOT NULL, "updatedAt" TIMESTAMP WITH TIME ZONE NOT NULL,
"CategoryId" INTEGER REFERENCES "Categories" ("id") ON DELETE CASCADE ON UPDATE CASCADE,
"PostId" INTEGER REFERENCES "Posts" ("id") ON DELETE CASCADE ON UPDATE CASCADE, PRIMARY KEY ("CategoryId","PostId"));
If you introspect the database with Prisma ORM, you'll get the following result in the Prisma schema (note that some relation field names have been adjusted to look friendlier compared to the raw version from introspection):
model Categories {
id Int @id @default(autoincrement())
name String
createdAt DateTime
updatedAt DateTime
PostCategories PostCategories[]
@@map("category")
}
model PostCategories {
createdAt DateTime
updatedAt DateTime
CategoryId Int
PostId Int
Categories Categories @relation(fields: [CategoryId], references: [id])
Posts Posts @relation(fields: [PostId], references: [id])
@@id([CategoryId, PostId])
@@map("PostCategories")
}
model Posts {
id Int @id @default(autoincrement())
title String
content String?
published Boolean? @default(false)
createdAt DateTime
updatedAt DateTime
authorId Int?
Users Users? @relation(fields: [authorId], references: [id])
PostCategories PostCategories[]
@@map("post")
}
In this Prisma schema, the many-to-many relation is modeled explicitly via the relation table PostCategories
By adhering to the conventions for Prisma relation tables, the relation could look as follows:
model Categories {
id Int @id @default(autoincrement())
name String
posts Posts[]
@@map("category")
}
model Posts {
id Int @id @default(autoincrement())
title String
content String?
published Boolean @default(false)
authorId Int?
author User? @relation(fields: [authorId], references: [id])
categories Categories[]
@@map("post")
}
This would also result in a more ergonomic and less verbose Prisma Client API to modify the records in this relation, because you have a direct path from Post
to Category
(and the other way around) instead of needing to traverse the PostCategories
model first.