prisma-local@postgress container times out with

Exception in thread "main" java.util.concurrent.TimeoutException: Futures timed out after [30 seconds]

→ npx prisma-upgrade ./prisma.disable.yml prisma/schema.prisma

Error Error parsing the Prisma 2 file.

Are you sure "/backend/prisma/schema.prisma" is a valid Prisma 2 schema file?

Run `prisma-upgrade -h` for more details.

Stack Trace:

  SyntaxError: Expected "=", "}", [ \t\n\r], or [A-Za-z] but "@" found.

I am getting this error after running

npx prisma db pull

on a Prisma 1 generated database, unfortunately I cannot share the generated file but hope to get some indication on how I could solve this. When I open the file in my editor with the Prisma extension it does not show any errors

If anyone is going through the Prisma 1 to 3 migration, I just got mine completed and intro production. AMA 🤣 I’m still trying to work through getting the database in sync with my schema.prisma file (kind of a nightmare) but my Nexus server and Prisma client is playing well with the db.

@lawjolla Nice! Did you have a generated GraphQL CRUD API in prisma 1? That part appeared to be missing from 2/3 last time I looked

Hi guys! I am in the middle of migration from prisma to prisma2. And I have a problem using custom prisma2 resolvers for nested objects of prisma1. I am aware of that if I want to get nested fields with Graphql query I need to use custom resolver as the docs says. Is it possible to fetch nested data which is available only in prisma2, using prisma1 query? Is it possible to create resolver which will use prisma2 to fetch nested object while using prisma1 client? For example:

type User {

id: String

stats: Stats

}

type Stats {

id: String

}

I have User in prisma1 and prisma2. And I have stats in prisma2 only. When I am overriding whole user query to prisma2 it works good with custom resolver to receive stats:

User {
 stats: (parent, args, context) => {
  return context.newPrisma.user.findUnique({
    where: { id: parent.id },
  }).stats();
 }
}

But when I won't override user query to new prisma and will use old prisma to fetch user, it won't use stats resolver 😞 Is it possible to somehow force graphql/prisma to use prisma2 resolver inside prisma1 query? I've noticed that when I am using prisma1 for query it tries to use relation table _UserToStats which I ofc don't have as I've migrated Stats and it's relation to User to prisma2. Is it possible to tell graphql yoga not to append relation table part? And use my custom resolver for stats, which will query it based on prisma2? This is only simple example, application is complex so I would like to somehow keep it consistent for now and migrate it gradually. Thanks in advance and have a great day!

Hi you all, many of you are migrating from prisma1 to prisma2. How do you solve the new API in the WhereInputObjects? We want as little as possible API changes, so we still want things like

createdAt_lte:

on the outside and transform it to

createdAt: { lte:

for prisma.

where: {createdAt_lte:"", createdAt_gt:""} => where: {createdAt:{lte:"",gt:""}}

Of course it's easy to write a recursive mapper for this. But I think there used to be a community driven project for exactly this problem. But I can't find it anymore. Do you know a module for this?

Hi folks! I have a question about.... prisma1 (sorry, I know but I can't update that project now and it's a simple question). I made a change in my database and then I executed prisma1 instrospect. Do I need to execute prisma1 deploy to see the changes? Because my graphql API doesn't reflect the changes (new column on a table) My intention is to make migrations with SQL scripts not changing the datamodel. A workaround I found is: Change database Execute introspect Run prisma1 deploy --no-migrate

There are some breaking bugs in the Prisma1 admin interface (the one present in the latest 1.34 images), there are reports in the old admin-feedback repo, but I linked them into a new bug report on the prisma1 repo. Is that something that can be expected to be fixed? Presumably they are pretty easy things to fix.

I'm upgrafing my prisma1 to a newer version of prisma. Should I go straight to version 3 or would it be better to go to version 2 first?

I don't think there is a particular reason to go to 2? 3 is more about the features added, the underlying design is the same as 2 (I think)

@Pedro Roque straight to version 3! There's no particular reason to go to 2 first.

Thank you, I'm running the queries from the prisma upgrade and I'm having an issue with updating the enums. Query:

CREATE TYPE "default$default"."Type" AS ENUM ('BULK', 'SHOP', 'TBC');
ALTER TABLE "default$default"."Order" ALTER COLUMN "type" SET DATA TYPE "default$default"."Type" using "type"::"default$default"."Type";

ERROR: default for column "type" cannot be cast automatically to type "default$default"."Type" SQL state: 42804 Any ideias why this is happening? I'm still new to postgres

Hi folks! I'm trying to run

prisma1 deploy --no-migrate

but I'm receiving migration validation errors like this one:

The underlying column for the field "status" has an incompatible type. The field has type "Enum" and the column has type "String"

. I have two questions: 1. Why if I use the --no-migrate flag prisma is running migration validations? 2. Why the error says that Enum is not compatible with String? Prisma creates Enum datamodel field as varchar(191). Is this a bug?

Hi folks. Which is the best way to do deploys on prisma1? What if I have traffic to my db while the deploy is in progress? I have problem with that and mutations. Mutations try to lock the table but the manager did it before so my mutations start to fail with the error

Deadlock found when trying to get lock; try restarting transaction

.

🚨 Hello <!channel>! On September 1st, 2022 we will change the status of Prisma 1 Open Source Software from “maintenance mode” to “deprecated”. This means that we will archive the Prisma 1 GitHub repo and we will no longer provide fixes for critical bugs, develop new features, or provide support for user issues - more information here. As a reminder, on September 1st we will also sunset Prisma 1 Cloud (free and paid) (login: app.prisma.io) - more information here.

set the channel topic: 🚨 This is a * community only * channel! On Sep 1st, 2022, Prisma 1 Cloud will be sunset and Prisma 1 Open Source (self-hosted) will be deprecated.

prisma1 delete not only removes the service from the prisma servere but it also delete the database. why isn't docummented this behavior? and also, is there a way to only remove the prisma service and NOT the database?

Is there any recommendation to set CONNECTION_LIMIT ? I saw documentation for current versions of prisma but for prisma1 I did not find any advice

This is a final reminder that you have until September 1st, 2022 to close your Prisma 1 Cloud account (prisma.io/cloud). We will also archive the Prisma 1 Open Source GitHub repo and we will no longer provide fixes for critical bugs, develop new features, or provide support for user issues - more information here.

Hi @channel, We are having trouble finishing the migration from Prism1 to Prisma3. Our prisma3 is using a GraphQL connect to a PostgreSQL on AWS. We did most of the work but are stuck on a few last errors (schema ambiguity). We are looking for help (either freelancer and/or expert Prisma3). Any recommendations? CC @Kevin Justal, our lead developper. Here is the type of errors we are getting.

ERROR: There is a relation ambiguity during the migration. Please first name the old relation on your schema. The ambiguity is on a relation between CustomerSubscription and Plan. Please name relations or change the schema in steps.

{

"data": {

"deploy": null

},

"errors": [

{

"locations": [

{

"line": 2,

"column": 9

}

],

"path": [

"deploy"

],

"code": 3018,

"message": "There is a relation ambiguity during the migration. Please first name the old relation on your schema. The ambiguity is on a relation between CustomerSubscription and Plan. Please name relations or change the schema in steps.",

"requestId": "local:cl6diaxtq001t0818wi9ql9jp"

}

],

"status": 200

}

Hey guys and and girls. So I'm currently working on upgrading out code to prisma 3 or 4 from prisma1 and I've noticed a diference between the schemas that prisma 4 generates compared to 1. So fields with the type Int[] prisma one makes an extra table. ie: Product_prices While prisma4 has that field in the same table. (Product) What's the best way to upgrade this data type? Is there a way to keep using the old tables or will I need to copy all the data over to the parent table (product)? Any ideas ? Thanks 🙂

Good Afternoon Gentlemen. I have another question regarding prisma1 upgrade. Currenlty I'm updating the datamodel and I'm not sure how to do this relation in prisma4. Any ideias? adultVersion: GarmentType @relation(name: "GarmentTypeAdultChild") childVersion: GarmentType @relation(name: "GarmentTypeAdultChild", link: TABLE)

Anyone on here that are actually running prisma1 in an active k8s cluster? As I slightly ramp up requests (there are some bursts from dashboard types of frontends) , the prisma nodes crash/throw exceptions after reaching a max (500) of mongodb threads. There is nothing that resembles CPU or memory issues. Is this some form of configuration that I can do anything with? Why isn't 500 threads enough for what is still a fairly low number of requests?

@andrewicarlson FYI

Waited till the last week to migrate off of the prisma 1 cloud..... wish me luck

I've migrated from 1 to 3, but when I db pull, my field names are singular and capitalized. E.g. Prisma 1 schema type User { … posts: Post[] } Vs Prisma 3 db pull model User { … Post: Post[] … } What am I missing?

Hi, I've asked this question last year, but I'm not sure if Ryan is still at Prisma 😄 Anyone?: https://prisma.slack.com/archives/C0152UA4DH9/p1637163031019400

Hello all, As mentioned here: https://prisma.slack.com/archives/C0152UA4DH9/p1656690261741449 The prisma 1 cloud will be sunset. We are in the middle of a migration but our production is still using prisma1 self-hosted on our private server on AWS. We are using the app.prisma.io to look at our data but not using anything thing cloud related. Will we be affected by the change ?

hi folks, wondering if anyone knows how to set the connection pool timeout for prisma1? i see the docs for current version here but haven’t been able to find a similar reference for prisma1

@Jeff Gardner What database do you have? For mongodb, this should be settable via the connection string