fastify-typescript icon indicating copy to clipboard operation
fastify-typescript copied to clipboard

Published 20 hours ago • verified publisher icon hmake98

chore(deps): update prisma monorepo

Open renovate[bot] opened this issue 4 years ago • 0 comments

WhiteSource Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
@prisma/cli (source) 2.14.0 -> 2.20.1 age adoption passing confidence
prisma (source) 2.17.0 -> 2.21.2 age adoption passing confidence

Release Notes

prisma/prisma

v2.20.1

Compare Source

Today, we are issuing the 2.20.1 patch release.

Fix

v2.20.0

Compare Source

Today, we are excited to share the 2.20.0 stable release :tada:

:star2: Help us spread the word about Prisma by starring the repo or tweeting about the release. :star2: 

Major improvements & new features
Count on relations (Preview)

This highly requested feature is now in Preview. You can now count the number of related records by passing _count to the select or include options and then specifying which relation counts should be included in the resulting objects via another select.

For example, counting the number of posts that an user has written:

const users = await prisma.user.findMany({
  include: {
    _count: {
      select: { posts: true },
    },
  },
})

The structure of the returned User objects is as follows:

{
  id: 1,
  email: '[email protected]',
  name: 'Alice',
  _count: { posts: 2 }
}

You can enable this featrues with the selectRelationCount feature flag:

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["selectRelationCount"]
}

There may be some rough edges during the Preview period. If you run into any problems, you can reach us in this issue.

napi is now in Preview

N-API is a new technique for binding Prisma's Rust-based query engine directly to Prisma Client. This reduces the communication overhead between the Node.js and Rust layers when resolving Prisma Client's database queries.

You can enable this feature with the napi feature flag:

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["napi"]
}

Enabling the N-API will not affect your workflows in any way, the experience of using Prisma will remain exactly the same.

The N-API has different runtime characteristics than the current communication layer between Node.js and Rust.

There may be some rough edges during the Preview period. If you run into any problems, you can reach us in this issue.

New push operation available for arrays on PostgreSQL

PostgreSQL supports array data structures (sometimes also called scalar lists). As an example, consider the permissions field on the following User model:

model User {
  id          Int @​id @​default(autoincrement())
  permissions String[]
}

As of this release, you can append a new item to existing lists atomically with the push command:

await prisma.user.update({
  where: { id: 42 },
  data: {
    permission: {
      push: "chat:read",
    },
  },
})

Learn more in this issue.

groupBy and createMany are now Generally Available

For the pioneers among you, you can now remove the groupBy and createMany from your Preview features:

 generator client {
   provider        = "prisma-client-js"
-  previewFeatures = ["groupBy", "createMany"]
 }

Learn more in our documentation about groupBy and createMany.

Prisma Client Go now supports BigInt, Decimal and Bytes

Prisma Client Go continues to get more powerful every release. With this release, we've added support for more native database types: BigInt, Decimal and Bytes:

var views db.BigInt = 1
bytes := []byte("abc")
dec := decimal.NewFromFloat(1.23456789)
created, err := client.User.CreateOne(
  db.User.Picture.Set(bytes),
  db.User.Balance.Set(dec),
  db.User.Views.Set(views),
).Exec(ctx)
Breaking changes
The @prisma/cli package has reached its end of life

For all you holdovers, you've seen warnings like this for a couple months now:

warn @​prisma/cli has been renamed to prisma.
Please uninstall @​prisma/cli: npm remove @​prisma/cli
And install prisma: npm i prisma

It's now time to upgrade. Follow the instructions and switch over to the new prisma package today:

npm
npm remove @​prisma/cli
npm install -D prisma

Thanks to this change, running npx prisma will now always invoke the right Prisma CLI, no matter what your local setup looks like.

Yarn
yarn remove @​prisma/cli
yarn add -D prisma
Upcoming breaking changes in the next version (2.21.0)
.aggregate will change to return null in 2.21.0

Subscribe to this issue for updates on how to prepare your code.

Fixes and improvements
Prisma Migrate
Prisma Client
Language tools (e.g. VS Code)
Security Fixes

We fixed two security issues:

Big thanks to @​erik-krogh (Erik Krogh Kristensen) and @​Ry0taK for reporting these issues.

Credits

Huge thanks to @​endor, @​iBluemind, @​matthewmueller, @​paularah, @​Iamshankhadeep for helping!

:tv: Join us for another "What's new in Prisma" livestream

Learn about the latest release and other news from the Prisma community by joining us for another "What's new in Prisma" livestream.

The stream takes place on Youtube on Thursday, April 01 at 5pm Berlin | 8am San Francisco.

v2.19.0

Compare Source

Today, we are excited to share the 2.19.0 stable release :tada:

:star2: Help us spread the word about Prisma by starring the repo or tweeting about the release. :star2: 

Major improvements & new features
Prisma Migrate is now ready for General Availability :rocket:

We are excited to announce that Prisma Migrate enters General Availability. You can learn more about the launch in the announcement article.

There are no major changes to how Prisma Migrate works except that the --preview-feature flag is being removed:

Before v2.19.0

npx prisma migrate <COMMAND> --preview-feature
for example:
npx prisma migrate dev --preview-feature

Now

npx prisma migrate <COMMAND>
for example:
npx prisma migrate dev

Besides making Prisma Migrate ready for production in this release, it comes with a number of smaller fixes and improvements:

  • After migrate dev, migrate reset and db push, generation is always triggered to avoid issues where the Prisma Client API is outdated due to changes in relation names which have an impact on the database schema (GitHub issue)
  • Improve UX when migrate dev produces warnings (GitHub issue)
  • Better error when adding a new required field and the default value is Prisma-level, e.g. uuid()
  • Small improvement where Prisma Migrate failed to create the database on DigitalOcean
  • Bugfix: Fix a bug when there are foreign keys referencing missing tables that resulted in a crash
  • Bugfix: Improvement when changing a field from type String to Enum (MySQL, PostgreSQL)
  • Bugfix: Improvement when migrating enums and a default enum value is defined (PostgreSQL)

:books: Documentation:

Order by aggregates of relations in Prisma Client queries (Preview)

This release makes it possible to order by the aggregates (e.g. count) of relations in your Prisma Client queries. Here's is an example that orders a list of users by the number of the posts they created:

const orderedUsers = await prisma.user.findMany({
  orderBy: {
    posts: {
      count: 'asc'
    }
  }
})

This feature is released in Preview which means you have to explicitly enable it via the orderByRelation feature flag in your Prisma schema:

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["orderByRelation"]
}

Don't forget to run npx prisma generate after you've added the feature flag to your Prisma schema so that the Prisma Client API gets updated accordingly.

Prisma Client Go now returns results from the Transaction API

Previously in the Go Client, you could write data within a transaction, but you couldn't get the results back from the transaction. Now you can! Learn more in the documentation.

Fixes and improvements
Prisma Client
Prisma Migrate
Language tools (e.g. VS Code)
Prisma Studio
Credits

Huge thanks to @​endor, @​iBluemind, @​meeq for their help in this release! :sparkles:

:briefcase: Learn about Enterprise use cases of Prisma on March 25th

We hope you join us for the upcoming Prisma Enterprise Event on Thursday, March 25th which is centered around the following topics:

  • Learn how top companies are addressing the challenges of data at scale
  • Discover how companies use Prisma to make their developers more productive
  • Get a better understanding of the future of data in the enterprise
:tv: Join us for another "What's new in Prisma" livestream

Learn about the latest release and other news from the Prisma community by joining us for another "What's new in Prisma" livestream.

The stream takes place on Youtube on Thursday, March 18 at 5pm Berlin | 8am San Francisco.

v2.18.0

Compare Source

Today, we are excited to share the 2.18.0 stable release :tada:

:star2: Help us spread the word about Prisma by starring the repo or tweeting about the release. :star2: 

Major changes & improvements

prisma introspect is becoming prisma db pull

In 2.10.0 we introduced the prisma db push command that enables developers to update their database schema from a Prisma schema file without using migrations.

For the "opposite" motion (i.e., updating the Prisma schema from an existing database schema), we currently have the prisma introspect command. In this release, prisma introspect is being renamed to prisma db pull. However, the prisma introspect command will be kept around for a few more releases so that you have enough time to switch over to the new command.

Here is how we are planning to execute the renaming:

  1. In this release, we are introducing a new command prisma db pull, which behaves exactly the same as prisma introspect.
  2. We will at some point in the near future add a deprecation warning to the prisma introspect CLI command.
  3. Eventually, prisma introspect will be removed.

There is no specific timeline to execute on this deprecation and we want to make sure we give developers a generous period of time to switch over.

Relation syntax will not be updated automatically any more

Prisma has a set of rules for defining relations between models in the Prisma schema.

The prisma format command automatically helps to apply these rules by inserting missing pieces. As an example, consider this data model with an invalid relation:

model User {
  id    String  @&#8203;id
  name  String?
  posts Post[]
}

model Post {
  id       String  @&#8203;id
  authorId String?
  author   User?   // not valid because the `@relation` attribute is missing
}

This example is not valid because the @relation attribute is missing. Running npx prisma format, automatically inserts the missing attribute:

model User {
  id    String  @&#8203;id
  name  String?
  posts Post[]
}

model Post {
  id       String  @&#8203;id
  authorId String?
+ author   User?   @&#8203;relation(fields: [authorId], references: [id])
}

In previous releases, this expansion logic was applied automatically in several scenarios without running the formatter (by running npx prisma format explicitly, or formatting via VS code), e.g. when running prisma migrate. While helpful in some scenarios, these "magic" insertions often resulted in others errors that were harder to interpret and to debug for developers and ourselves.

In this release, the "magical" instertions are removed and developers need to explicitly run npx prisma format if they want still make use of them.

More flexible seeding in TypeScript

The ts-node command options can now be customized via package.json to pass specific options to ts-node. This makes prisma db seed work with tools that have specific requirements when used with TypeScript, such as Next.js.

Here is an example that works with Next.js:

{
  "name": "my-project",
  "version": "1.0.0",
  "scripts": {
    "ts-node": "ts-node --compiler-options '{\"module\":\"CommonJS\"}'"
  },
  "devDependencies": {
    "@&#8203;types/node": "^14.14.21",
    "ts-node": "^9.1.1",
    "typescript": "^4.1.3"
  }
}
New Upsert API for Prisma Client Go

Prisma Client Go now supports upsert operations:

post, _ := client.Post.UpsertOne(
    // query
    Post.ID.Equals("upsert"),
).Create(
    // set these fields if document doesn't exist already
    Post.Title.Set("title"),
    Post.Views.Set(0),
    Post.ID.Set("upsert"),
).Update(
    // update these fields if document already exists
    Post.Title.Set("new-title"),
    Post.Views.Increment(1),
).Exec(ctx)

Learn more in the documentation and share your feedback in the #prisma-client-go channel on Slack.

Fixes and improvements

Prisma Client
Prisma Migrate
Prisma Studio
Language tools (e.g. VS Code extension)
Prisma engines

:pencil: Help us improve our release notes

We want to ensure our release notes are as helpful as possible for you! You can help us achieve this by taking part in the poll in this GitHub issue.

:tv: Join us for another "What's new in Prisma" livestream

Learn about the latest release and other news from the Prisma community by joining us for another "What's new in Prisma" livestream.

The stream takes place on Youtube on Thursday, March 04 at 5pm Berlin | 8am San Francisco.

v2.17.0

Compare Source

Today, we are excited to share the 2.17.0 stable release :tada:

:star2: Help us spread the word about Prisma by starring the repo or tweeting about the release. :star2: 

Overview

  • Native types are now stable
  • Prisma Migrate now works with cloud-hosted databases (e.g. Heroku)
  • Soft resets for cloud-hosted environments
  • More improvements and bug fixes for Prisma Migrate
  • Improvements and changes for prisma db push
  • prisma db seed now supports custom schema locations
  • Improvements and bug fixes in Prisma Client

Note that this release comes with some breaking changes. Read the Breaking changes section below to learn more.

Major improvements & new features

Native types are now stable

The nativeTypes preview feature flag has first been introduced in 2.10.0. Thanks to your continuous and awesome feedback for this feature, we're now able to release usage of native database types in the Prisma schema for General Availability :tada:

Note that this release comes with a few minor breaking changes compared to previous versions. Please read about the Breaking Changes below.

If you haven't followed previous releases, expand below to learn more about everything that's now possible with the new native types.

Expand to learn more about the benefits of native types ##### Rich column type mapping for Prisma types

Each Prisma type can now map to one of multiple native database types. Native database type attributes are:

  • Specific to the underlying provider - for example, PostgreSQL uses @db.Boolean for Boolean whereas MySQL uses @db.TinyInt
  • Written in PascalCase (for example, VarChar or Text)
  • Prefixed by @db, where db is the name of the datasource block in your Prisma schema

Type attributes give you:

  • Exact control over what native type Prisma Migrate creates in the database - for example, a String can be @db.VarChar(200) or @db.Char(50)
  • An enriched schema when you introspect - you can see if String is varchar(200) or just text.

To learn more about all the possible native type attributes, check out the type mapping reference in the docs.

Extending Prisma schema beyond supported column types

Column types which are not (yet?) supported by Prisma Migrate can be used with Prisma Migrate and introspection through the Prisma type Unsupported which was introduced in Preview in the last release:

model User {
  id                    Int     @&#8203;id @&#8203;default(autoincrement())
  email                 String  @&#8203;unique
  name                  String? @&#8203;default("")
  multilinestringField  Unsupported("multilinestring") @&#8203;unique
}

dbgenerated() in the @default directive can now take a String argument that enables developers to reflect database-level DEFAULT constraints not yet supported by Prisma Migrate. These default values will be surfaced when introspecting with prisma introspect and created/changed when using Prisma Migrate.

Developers can now add @@&#8203;ignore and @ignore attributes to models and fields, for fields they want to manage via Prisma Migrate but not surfaced in Prisma Client. These attributes are added by Prisma when introspecting entities which are not supported, e.g. a table with no unique column. They are now also kept in the Prisma schema when re-introspecting a database.

##### Prisma Migrate now works with cloud-hosted databases (e.g. Heroku)

Before this release, Prisma Migrate could be used to apply migrations in a cloud-hosted environment (CI/CD pipeline, manual deployment to production, staging, etc.), but it was impossible to create new migrations, due to the requirement of a shadow database. Prisma Migrate expects to have privileges to create the shadow database using the same credentials, but cloud providers generally do not allow creating logical databases.

Starting from this release, prisma migrate dev can now be used in development with cloud-hosted databases by configuring a separate connection URL for the shadow database.

To develop natively in the cloud with Prisma Migrate, developers can create two cloud-hosted databases, one being the development- and the other being the shadow-database.

The connection URI for the shadow database can be configured in the datasource block of the Prisma schema file, similarly to the datasource URL, by defining a shadowDatabaseUrl variable:

datasource db {
  provider          = "postgresql"
  url               = env("DATABASE_URL")
  shadowDatabaseUrl = env("SHADOW_DATABASE_URL")
}
Soft resets for cloud-hosted environments

Another common limitation of cloud-hosted environments is that the database cannot be dropped and re-created using DROP DATABASE and CREATE DATABASE, due to insufficient privileges. Prisma Migrate so far relied on these statements to ensure the database is empty when it needs to be reset.

Database resets in the context of Prisma Migrate now gracefully fall back to dropping constraints, indexes and tables, if there are insufficient privileges to reset the database using DROP DATABASE.

Note that this comes with the caveat that there could be other entities in the database, which Prisma Migrate could fail to clean up.

More improvements and bug fixes for Prisma Migrate
  • Prisma Migrate has now a built-in locking functionality to prevent multiple migrations from running concurrently.
  • Ensure the Prisma schema is valid before prompting developers to reset the database.
  • Better error message when using migrate dev - if a non-interactive environment is detected, you'll be suggested to use prisma migrate deploy instead.
  • Improved error handling when Prisma Migrate finds empty migration directories, e.g. prisma/migrations/20210119114009_init (missing migration.sql file).
  • In some occasions, when dealing with invalid schemas, e.g., duplicate constraint names, a panic in the Migration Engine would be triggered. These errors are now surfaced as validation errors instead.
  • In certain cases, when dealing with UUID columns, Prisma Migrate would drop and re-create the columns every time a migration was generated. This has now been fixed.
Improvements and changes for prisma db push
  • prisma db push now handles unexecutable migrations better, offering a path forward by resetting the database. For example, adding a new required field without a default value when there are rows in the table is considered an unexecutable migration; in such situations you will be prompted to first reset the database.
  • Changes to command options:
    • The flag —-force has been renamed to --accept-data-loss to be more explicit - this is required for certain changes that involve losing data, e.g. dropping a table or dropping a column if there are rows.
    • We've added a new flag —-force-reset which first resets the database and then updates the schema - this can be useful to start from scratch and as a way to deal with unexecutable migrations (see above).
prisma db seed now supports custom schema locations

You can now point the prisma db seed command to a custom schema location using either of two approaches:

  • Use the --schema option when running the command
  • Define a default schema location in your package.json which will be picked up every time you run the command.
Improvements and bug fixes in Prisma Client
  • Transaction rollback fix: We fixed an issue where if there was an error within the Prisma Client's runtime validation, the transaction wouldn't rollback. Learn more in this issue.
  • SQL Server server_name fix: Before we couldn't connect to certain kind of SQL Server instances. If the server was a managed instance from Azure, connecting to it with Prisma would return Server name cannot be determined. Additionally, when running a shared Azure SQL database, if the firewall setting was set to redirect (the default setting), our connection would first fail with advising the user to connect to a new server, and when changing the connection string regarding the error, the new connection would fail with the same error Server name cannot be determined. This is now fixed. Azure managed instances just work, as do redirections (which are done under the hood, automatically).
  • Native type fix for SQL Server: Our native type validations limits were set too low. We'd consider the maximum of 2000 for NVarChar/NChar length and a maximum of 4000 for VarChar/Char/VarBinary/Binary length. The actual maximums are 4000 for first and 8000 for the latter types.
  • PostgreSQL numeric type fix: In certain cases, when using executeRaw to insert number values to a numeric type in PostgreSQL, sometimes the stored value would be zero instead of the user input. An example value of 12345.0 is converted by JavaScript as an integer of 12345, which then is written as an integer to the table. The table column being numeric, the integer representation would always be zero in these cases. Now we should be able to convert integers to numeric without any trouble.
Bug fixes in Prisma Studio
  • Studio can now display fields that are of type Byte and BigInt.
  • Usage of the createMany preview feature doesn't crash Studio any more

Breaking changes

Type mapping from Prisma schema to the database for Float has changed from Decimal to Double in MySQL and PostgreSQL
Overview

If you use the Float scalar type in your Prisma schema and used Prisma Migrate to create the database schema in previous Prisam versions, the corresponding database column has the type DECIMAL(65,30).

For example, given the following Prisma schema:

model Post {
  id        Int     @&#8203;id @&#8203;default(autoincrement())
  title     String
  content   String?
  reward    Float // Previously mapped to DECIMAL(65,30). From 2.17.0 will map to Double
  published Boolean @&#8203;default(false)
}

Previous version of Prisma Migrate would generate the following migration:

-- CreateTable
CREATE TABLE "Post" (
    "id" SERIAL NOT NULL,
    "title" TEXT NOT NULL,
    "content" TEXT,
    "reward" DECIMAL(65,30) NOT NULL, // 
    "published" BOOLEAN NOT NULL DEFAULT false,
    PRIMARY KEY ("id")
);

As of 2.17.0, the remapping of the Float type from Decimal(65,30) to Double will cause Migrate to attempt to alter the database type of the reward column to Double the next time you create a migration.

What does this mean for users?

Nothing changes in Prisma Client until the next time you want to make a change to your schema. In that case, you'll need to decide if you want to keep using the Decimal(65,30) type in the database:

  • If you want to continue using Decimal(65,30), you need to change the type in the Prisma schema from Float to Decimal. Alternatively, you can also run prisma introspect which will automatically remap the previous Float fields to Decimal. Note that this will also change the type that Prisma Client returns from Number to Decimal.js.
  • If you would like to change the column's type in the database from Decimal(65,30) to Double, leave the Prisma schema as is and create a new migration. Prisma Migrate will alter the column's type to Double. Note that if you have rows with data for the column, they will be cast from Decimal(65,30) to Double.

Check out this video guide, which covers how to upgrade and address the remapping of Float.

Breaking changes due to strict type diffing and native types
Overview

Prisma has default mappings between each scalar type in the Prisma schema to the underlying database type. For example, the String scalar type in Prisma schema is mapped to a TEXT column on PostgreSQL by default.

Before this release, Prisma supported using a range of database column types for a given Prisma scalar. For example, define a field in Prisma schema as String and use VARCHAR(50) as the column type in the database using the @db.varchar(50) type annotation .

With the introduction of native types in General Availability, you can now specify your desired database type for columns in the Prisma schema via the @db.DB_TYPE field attributes, e.g., @db.varchar(50).

Because the @db.DB_TYPE attribute now exists, Prisma no longer allows the loose mapping of Prisma scalar types to database column types without the specific notation. The only exception to this rule is when you want to use default mapping, e.g., the String Prisma scalar will map to TEXT on PostgreSQL.

Before

Given the following table in PostgreSQL:

-- CreateTable
CREATE TABLE "User" (
    "id" SERIAL NOT NULL,
    "nickName" VARCHAR(50),
    "name" TEXT NOT NULL,

    PRIMARY KEY ("id")
);

Prisma would introspect the table as follows:

model User {
  id       Int      @&#8203;id @&#8203;default(autoincrement())
  nickName String?  //defaults to TEXT on PostgreSQL but works with varchar
  name     String   //defaults to TEXT on PostgreSQL but works with varchar
}
After

Because VARCHAR(50) can be expressed in native type notation. The matching Prisma schema for the User database table above on PostgreSQL is the following:

// Example for PostgreSQL

model User {
  id       Int      @&#8203;id @&#8203;default(autoincrement())
  nickName String?  @&#8203;db.VarChar(50) // Prisma expects the column to be varchar and Prisma Migrate will change it if not
  name     String   // Prisma expects the column to be of type TEXT (default for String) and Prisma Migrate will change it if not
}
What does this mean for users?

Moving forward, if you want specific database column types, which are supported by Prisma, you should make sure to use the native type notation for the corresponding fields in the Prisma schema.

For users of Prisma Migrate with existing databases, you must understand that Prisma Migrate will try to migrate every column of a type different than what's defined in the schema.

If we go back to the previous example with loose type mapping, with this Prisma schema:

model User {
  id       Int      @&#8203;id @&#8203;default(autoincrement())
  nickName String?  //defaults to TEXT on PostgreSQL but works with varchar
  name     String   //defaults to TEXT on PostgreSQL but works with varchar
}

and this initial database schema:

-- CreateTable
CREATE TABLE "User" (
    "id" SERIAL NOT NULL,
    "nickName" VARCHAR(50),
    "name" TEXT NOT NULL,

    PRIMARY KEY ("id")
);

On PostgreSQL, from this release on, Prisma will the columns for the fields nickName and name to be of type TEXT and will generate a migration to alter the type of the nickName column:

-- AlterTable
ALTER TABLE "User" ALTER COLUMN "nickName" SET DATA TYPE TEXT;

To avoid unnecessary migrations to change types you may have defined on purpose, you can run introspection once, which will add the native annotations to any fields when they do not match the default mappings by Prisma.

For the initial database schema we used in the example

-- CreateTable
CREATE TABLE "User" (
    "id" SERIAL NOT NULL,
    "nickName" VARCHAR(50),
    "name" TEXT NOT NULL,

    PRIMARY KEY ("id")
);

This would be the resulting Prisma schema after running prisma introspect

model User {
  id       Int      @&#8203;id @&#8203;default(autoincrement())
  nickName String?  @&#8203;db.VarChar(50)
  name     String   
}

Fixes and improvements

Prisma Client
Prisma Migrate
Language tools
Prisma Studio
Prisma Engines

Check out the official Prisma roadmap

You can find all the features that are currently planned and in progress on our roadmap.

Credits

Huge thanks to @​safinsingh for helping!

v2.16.1

Compare Source

Today, we introduce the 2.16.1 patch release.

This fixes a problem some users are having with certain Docker, MariaDB, MySQL or SQL Server configurations, preventing Prisma to connect with localhost. A recent Docker update caused a regression related to IPv6 and name resolution.

Prisma
Prisma Engines

v2.16.0

Compare Source

Today, we are excited to share the 2.16.0 stable release :tada:

:star2: Help us spread the word about Prisma by starring the repo or tweeting about the release. :star2: 

Major improvements
The Prisma CLI moves from the @prisma/cli to the prisma npm package

Going forward, you can install the Prisma CLI via the prisma npm package:

npm install prisma --save-dev

or

yarn add prisma --dev

The reason for this is that a number of users were experiencing issues when running the npx prisma command. Without a local installation of the @prisma/cli package, this would invoke the Prisma 1 CLI leading to an error message. From now on, npx prisma is always going to work.

We will also deprecate the @prisma/cli package. Please do a find and replace across your codebase to transition over from @prisma/cli to prisma. To make this transition easier, we'll keep publishing updates to both packages for another month and plan to stop updating the @prisma/cli package with release 2.18.0.

There are no changes to the @prisma/client npm package name.

Efficient bulk creates with createMany

Insert data a whole lot faster with createMany. Here's an example:

const result = await prisma.user.createMany({
  data: [
    { email: "[email protected]" },
    { email: "[email protected]" },
    { email: "[email protected]" },
    { email: "[email protected]" },
  ],
});

console.log(`Created ${result.count} users!`);

This feature is in preview right now. Enable it with the createMany preview flag:

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["createMany"]
}

:books: Documentation: Create multiple records

Learn more in this issue.

Order by relation fields with orderBy

Ever wish you could order posts by an author's name? Or sort transactions by account? Now you can! We've expanded orderBy to support ordering by relations:

cons posts = await pr</details>

---

### Configuration

:date: **Schedule**: At any time (no schedule defined).

:vertical_traffic_light: **Automerge**: Disabled by config. Please merge this manually once you are satisfied.

:recycle: **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

:ghost: **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://togithub.com/renovatebot/renovate/discussions) if that's undesired.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box.

---

This PR has been generated by [WhiteSource Renovate](https://renovate.whitesourcesoftware.com). View repository job log [here](https://app.renovatebot.com/dashboard#github/hmake98/fastify-typescript).

renovate[bot] avatar Mar 06 '21 13:03 renovate[bot]