Prisma Latest Version

[Tamela]

PrismaORM 5.0.0 introduces a number of changes, including the usage of our new JSON Protocol, which make Prisma Client faster by default. A full list of these changes can be found in our release notes.

Prisma ORM 5 includes some minimum version changes for Node.js, TypeScript, and PostgreSQL. To use Prisma version 5.0.0 and up, you will need to have at least the minimum versions below:See our system requirements for all minimum version requirements.

Node.js v16.x is reaching end-of-life on 11 September 2023 in order to coincide with the end-of-life of OpenSSL 1.1.1. For that reason, we recommend upgrading to the current Node.js LTS, v18.x. Please note that Prisma ORM 5 will be the last major version of Prisma ORM to support Node.js v16.

While Prisma ORM supports PostgreSQL versions 9.6 and above, we strongly recommend updating to a version that is currently supported and still receiving updates. Please check PostgreSQL's versioning policy to determine which versions are currently supported.

With Prisma ORM version 5.0.0, we have upgraded the embedded version of SQLite from 3.35.4 to 3.41.2. We did not see any breaking changes and don't anticipate any changes needed in user projects, but if you are using SQLite, especially with raw queries that might go beyond Prisma ORM's functionality, make sure to check the SQLite changelog.

With Prisma ORM 5, the deprecated parameter rejectOnNotFound has been removed. Depending on if your project used rejectOnNotFound per query or globally, there will be be different ways of updating your code.

The jsonProtocol preview feature is now Generally Available. This new protocol leads to significantly improved startup times when compared to our previous GraphQL-based protocol. When upgrading to Prisma ORM 5, make sure to remove jsonProtocol from your preview features, if added.

Prisma ORM 5 drops support for a number of "array shortcuts". These shortcuts were a way to add a single element as a value to an array-based operator instead of wrapping that one element in an array. To make our typings more consistent and logical and to conform to the new JSON Protocol, we now require array values for these operators.

With Prisma ORM version 5.0.0, we require the cockroachdb provider to be used when connecting to CockroachDB databases. Previously, we had accepted postgresql as well, but we are removing that option.

Importing from @prisma/client/runtime is no longer available in Prisma ORM 5. If you were using public APIs available in this namespace before, you can instead import Prisma and access them. For example:

We highly discourage the use of internal private APIs as they can change without warning and are not guaranteed to be supported. If your usage requires a private API that was previous available please reach out to us on GitHub.

In the generated types, Address.user and Post.user would use the same type, UserRelationFilter. This is obviously unintended as Address.user is nullable while Post.user is not. In Prisma ORM 5, the type of Address.user would be UserNullableRelationFilter, resolving this issue.

In certain instances it was possible for name collisions to occur when one model had two foreign keys to two other models that had the same property name for the reverse relation. As an example, the following schema:

Would lead to conflicting names between the two relations on InvoiceItem. The reverse relations, that is Invoice.invoice_items and Track.invoice_items would both get the type InvoiceItemUncheckedUpdateManyWithoutInvoice_itemsInput. In Prisma ORM 5, this is resolved and Prisma Client will generate InvoiceItemUncheckedUpdateManyWithoutInvoicesInput and InvoiceItemUncheckedUpdateManyWithoutTracksInput respectively.

The following changes may cause an application to initially throw an error message after upgrading to Prisma ORM 5. Fortunately, they are easy to solve, as the underlying functionality has been removed for a while or the change is a simple string replace.

The beforeExit hook has been removed from the Prisma ORM library engine. While this functionality is still required for the Prisma ORM binary engine in order to run last minute queries or perform shutdown related operations, it provides no benefit over native Node.js exit hooks in the library engine. Instead of this hook we recommend using built-in Node.js exit events.

The engine responsible for commands like prisma migrate and prisma db has been renamed from migration-engine to schema-engine to better describe its use. For many users, no changes will be required. However, if you need to explicitly include or exclude this engine file, or refer to the engine name for any other reason, you will need to update your code references.

To any of you using the Cloudgenix Ion devices, do you have any version upgrade recommendations or best practices? Is anyone running 6.x successfully or are most staying with an older supported release like 5.6?

I had all our devices (Ion 3k,7k, 9ks) on 5.6.5-b15 which we didn't have too many problems with. During a reason network maintenance window I opted to upgrade to 6.1.1-b10, which has been a disaster, getting tons of reports of dropped zoom/teams calls and just general network issues. I'm debating if I should go back to 5.6.5-b16 and wait until 6.x is more stable or move to 6.2.1 in hopes that it alleviates my issue.

I have been trying to stick with versions that have more b revisions in the hopes of higher stability because they seem to update minor versions quickly and abandon them, but my recent experience with the 6.1.1-b10 branch makes me think this may not be the best strategy.

Anyone else have any thoughts on this? I really wish they had a software release guidance thread similar to Pan-OS where support can chime in and tell us which versions are stable or recommended and which are more beta or experimental.

From recent experience shadowing another engineer on a project, stay on 5.6. Avoid 6.2.1 for now for sure, 6.1.4 may be ok in some circumstances but probably wait for 6.1.5. Issues encountered include software proc restarts and false positives with tunnel monitoring. We are hoping for something better in 6.1.5 but are stuck with 6.1 on newer (ION3200, ION5200) boxes or we would probably be on 5.6 code. We are told by TAC that 6.5 should be available beginning of October.

I have been a running a mix of 6.1.3-b1 and 6.1.2-b5 on my CG3000 ION's. We were told that 6.1.3-b1 was the recommended support release in October. We haven't had issues reported while running these releases from our branches. Looking at my device list, we have had devices running 6.1.2-b5 since April 2023.

running 6.1.4-b2 on ION 5200s, ran into a new bug last week where AppID "enterprise-unknown" exists in traffic of the security policy causes failed LAN to LAN bi-directional communications. Requires a custom app-ID to identify as other than enterprise-unknown. Discussed upgrading but are afraid of running into new bugs. Thanks for you reply.

I reached out to support today since PA does not publish a recommended release. They referred me to my account team. The reply I received was 6.15b1 is the current recommended release for the 6.x version. I upgraded our lab ION from 6.1.3-b1 and it was a quick upgrade.

With both local and global omit, you now have the flexibility to completely remove sensitive fields while also tailoring individual queries. If you need the ability to generally omit a field except in a specific query, you can also overwrite a global omit locally

Previously, when the feature was enabled we updated the OrderByWithRelationInput TypeScript type with the OrderByWithRelationAndSearchRelevanceInput type. However, we have noted that there are no cases where relational ordering is needed but search relevance is not. Thus, we have decided to remove the OrderByWithRelationAndSearchRelevanceInput naming and only use the OrderByWithRelationInput naming.

When running commands where a Prisma Schema file is expected to be provided, you can now define a Prisma Schema directory. This includes Prisma CLI commands that use the --schema option as well as defining schema via package.json

Our tooling has also been updated to handle multiple Prisma Schema files. This includes our Visual Studio Code extension and tools like database introspection, which will deposit new models in a introspected.prisma file. Existing models will be updated in the file they are found.

This release fixes a nasty bug with the caching of prepared statements in raw Prisma Client queries that affected PostgreSQL when you ran the same SQL statement with differently typed paramters. This should not fail any more.

Our Introspection logic crashed on encountering certain multi-line CREATE DEFAULT, a deprecated way to define defaults in SQL Server. As many SQL Server users are working with established databases, this happened frequently enough that we now explicitly ignore these defaults instead of crashing.

Note: Because createManyAndReturn() uses the RETURNING clause, it is only supported by PostgreSQL, CockroachDB, and SQLite databases. At this time, relationLoadStrategy: join is not supported in createManyAndReturn() queries.

Previously, Prisma ORM suffered from performance issues when using the in operator or when including related models in queries against a MongoDB database. These queries were translated by the Prisma query engine in such a way that indexes were skipped and collection scans were used, leading to slower queries especially on large datasets.

We added a new parameter --output to migrate diff that can be used to provide a filename into which the output of the command will be written. This is particularly useful for Windows users, using PowerShell, as using > to write into a file creates a UTF-16 LE file that can not be read by wrangler d1 migrations apply. Using this new option, this problem can be avoided:

When using Prisma ORM with D1, you can continue to: model your database with Prisma schema language, specify sqlite as your database provider in your Prisma schema, and interact with your database using Prisma Client.

3a8082e126