hello team, Recently we have a live event with live chat feature. We have made the following pre-scale changes for yesterday’s event, But we have seen a lot of timeout from PRISMA server and even we faced PRISMA server down and restart situation, can anybody help us on that: ECS : app-server-prod: 8 tasks to 60 tasks prisma-worker-prod: 18 tasks to 80 tasks discussion-server-prod: 10 tasks to 100 tasks geolocation-service-prod: 2 tasks to 20 tasks EC2 : rabbitmq-cluster instance type changed from t3a.xlarge to m5.2xlarge. RDS : dw-prod: size changed from db.m5.8xlarge to db.m5.12xlarge dw-geo-location: size changed from db.t3.medium to db.t3.xlarge ElastiCache : dailywire-redis-prod: Node type changed from cache.m4.2xlarge to cache.m4.4xlarge geo-service-redis:  Node type changed from cache.m5.large to cache.m5.xlarge. We are already consider upgrading to Prisma 2 and started revieing how we can migrate to PRISMA v1 to PRISMA v2. Can also anyone provide technical support on this as well? I am really looking forward to this.

hello Team, I would like to get help on following things. How can i get raw query generated using PRISMA functions? How can we setup PRISMA 1 server as an autoscale ECS, can anybody help us on that? we are okay to have paid technical help as well.

Did anyone test deploying prisma1 using GCP Cloud Run? Been running it as AppEngine instances, but I generally like the Cloud Run setup better.

Hello! Does anyone have a problem connecting prisma with GraphQL?

I created a PostgreSQL on Heroku, I tried to connect using pgAdmin and everything works fine!

Then I create a prisma docker container and after doing that everything is working fine, but when I try retrieve some data I have this error:

org.postgresql.util.PSQLException: ERROR: relation “default.Post” does not exist Position: 113 at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2433) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2178) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:306) at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:441) at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:365) at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:155) at org.postgresql.jdbc.PgPreparedStatement.executeQuery(PgPreparedStatement.java:118) at com.zaxxer.hikari.pool.ProxyPreparedStatement.executeQuery(ProxyPreparedStatement.java:52) at com.zaxxer.hikari.pool.HikariProxyPreparedStatement.executeQuery(HikariProxyPreparedStatement.java) at com.prisma.connector.shared.jdbc.SharedSlickExtensions.$anonfun$queryToDBIO$1(SharedSlickExtensions.scala:17) at com.prisma.connector.shared.jdbc.SharedSlickExtensions.$anonfun$jooqToDBIO$1(SharedSlickExtensions.scala:56) at slick.jdbc.SimpleJdbcAction.run(StreamingInvokerAction.scala:70) at slick.jdbc.SimpleJdbcAction.run(StreamingInvokerAction.scala:69) at slick.basic.BasicBackend$DatabaseDef$$anon$3.liftedTree1$1(BasicBackend.scala:276) at slick.basic.BasicBackend$DatabaseDef$$anon$3.run(BasicBackend.scala:276) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) {“key”“error/unhandled”,“requestId”“localckux0718p002z0884c7120803”,“clientId”“default$default”,“payload”{“exception”“org.postgresql.util.PSQLException: ERROR: relation \“default.Post\” does not exist\n Position: 113",“query”:“{\n posts(first: 100, skip: 0) {\n id\n title\n body\n published\n author {\n id\n __typename\n __id: id\n }\n __typename\n __id: id\n }\n count: postsConnection {\n aggregate {\n count\n __typename\n }\n __typename\n }\n}\n”,“variables”“{}“,”code”“0”,“stack_trace”:“org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2433)\\n org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2178)\\n org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:306)\\n org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:441)\\n org.postgresql.jdbc.PgStatement.execute(PgStatement.java:365)\\n org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:155)\\n org.postgresql.jdbc.PgPreparedStatement.executeQuery(PgPreparedStatement.java:118)\\n com.zaxxer.hikari.pool.ProxyPreparedStatement.executeQuery(ProxyPreparedStatement.java:52)\\n com.zaxxer.hikari.pool.HikariProxyPreparedStatement.executeQuery(HikariProxyPreparedStatement.java)\\n com.prisma.connector.shared.jdbc.SharedSlickExtensions.$anonfun$queryToDBIO$1(SharedSlickExtensions.scala:17)\\n com.prisma.connector.shared.jdbc.SharedSlickExtensions.$anonfun$jooqToDBIO$1(SharedSlickExtensions.scala:56)\\n slick.jdbc.SimpleJdbcAction.run(StreamingInvokerAction.scala:70)\\n slick.jdbc.SimpleJdbcAction.run(StreamingInvokerAction.scala:69)\\n slick.basic.BasicBackend$DatabaseDef$$anon$3.liftedTree1$1(BasicBackend.scala:276)\\n slick.basic.BasicBackend$DatabaseDef$$anon$3.run(BasicBackend.scala:276)\\n java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\\n java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\\n java.lang.Thread.run(Thread.java:748)“,”message”“ERROR relation \“default.Post\” does not exist\n Position: 113"}}

How can i solve this error:

ERROR: relation “default.Post” does not exist?

Ok, so still trying to improve the prisma 1 setup in GCP. I want to protect the service with their IAM, but this requires the ability to add a bearer token to the headers. Is there a simple way to do this with the typescript client?

Hello! I’m not sure if this question is specific to prisma1, but is there a preferred method for getting the

updatedAt

field for a particular resource to update when you’re making a change to one of it’s inline relations? When I run the

updateProduct

method, and connect/update the Product’s

type

, the Product’s

updatedAt

value doesn’t change.

type Product {
  id: ID! @id
  type: ProductType!
  createdAt: DateTime! @createdAt
  updatedAt: DateTime @updatedAt
}

type ProductType {
  id: ID! @id
  createdAt: DateTime! @createdAt
  updatedAt: DateTime @updatedAt
}

await prisma.updateProduct({
  where: {
    id: existingProduct.id,
  },
  data: {
    type: {
      connect: {
        id: productTypeId,
      },
    },
  },
})

I am trying configuring stricter mongo user restrictions, but I see that I'm not sure I know exactly what is required - will using the normal client against e.g. the default_default db, also require access to the prisma db (maybe just read access?) for verification of the secret?

I have an issue where I in some context isn't able to create a prisma client (TS) (makePrismaClass returns, but with an invalid, promise-like object). I have traced this to, I think, that in the Client-class, the generateSelections function fails on line 275 (looking at the latest revision in the github repo). The debugger seems to suggest that instructions is undefined or similar when reduceRight is supposed to be called on it, causing a crash internally.

I have one situation where it consistently works, and another where it consistently fails, and except for superficial stuff, I have no idea what the difference is.

Can anyone with knowledge of the relevant code help in figuring this out?

Ok, I think I figured this out now. So the Client class has a then-function (which I think is used for when actual operations is called on the prisma client), but if you return the prisma client from an async function (I do some async requests to a secret store ahead of creating the client), the runtime presumably sees the then, thinks this is an actual promise, and then because I have await at the call site, the then on the client is executed, but now without the context of an operation such that it fails, upending the whole await/return process.

Rewriting to a non-async function fixed the issue.

And of course, easier than making it non-async is to just wrap the prisma client in an object prior to returning.

Hi. I want to upgrade postgres version on production (from 11 to 14). While most of the database schemas are used by Prisma 2, there's still one schema used by Prisma 1 Server. Is Prisma 1 compatible with Postgres 14? Couldn't find any info on Prisma 1 website.

To those with scaling issues, 99% of ours are nested queries. We solved it by putting the Prisma calls higher in the tree with a fragment. E.g. we had a query` query vehiclesForSale { vehicles(status: FOR_SALE) { ... images { ... tags { id tag } } } } ` And instead of letting Prisma construct that query all the way down, we intercepted it and used fragments. e.g., in the Vehicle type...

t.field("images", {
      list: true,
      type: "Image",
      resolve: async (parent: any, _, { prisma }) => {
        const images: any[] = await prisma
          .vehicle({ id: parent.id })
          .images({
            where: { AND: [{ access: ["Public"] }] },
            orderBy: `order_ASC`
          })
          .$fragment(
            `
          { id url order createdAt description access tags { id tag  }}
          `
          )
      return images
})})

You need need to be more careful about your data model. e.g. in this case, I'm only exposing a subset of the Tag type so the client needs to know it can't query the whole thing or any relations off of Tag

Hi everyone. Currently in my schema, I've got a relation between two entities:

type User {
  id: ID! @id
  link: Link @relation(link: INLINE, name: "LinkToUser")
}

type Link {
  id: ID! @id
  users: [User!]! @relation(name: "LinkToUser", onDelete: SET_NULL)
}

I'm now trying to add a different relation between these same entities:

type User {
  id: ID! @id
  link: Link @relation(link: INLINE, name: "LinkToUser")
  notificationLinks: [Link!]! @relation(name: "LinkNotificationUsers")
}

type Link {
  id: ID! @id
  users: [User!]! @relation(name: "LinkToUser", onDelete: SET_NULL)
  notifyUsers: [User!]! @relation(name: "LinkNotificationUsers", onDelete: SET_NULL)
}

however when I try to deploy the change, I get the following 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 Link and User. Please name relations or change the schema in steps.

I'm not sure how to fix this issue as, as far as I can tell, all I'm doing is deploying a named relation in addition to a pre-existing named relation. Any ideas?

Hello! When querying records using multiple filters (ie.

OR: [ ]

), is it possible to “tag” which records were returned from which filter? Example:

const filteredPosts: Post[] = await prisma.posts({
  where: {
    OR: [
      {
        description_contains: 'graphql',
      },
      {
        description_contains: 'prisma',
      },
    ],
  },
})

And our results with tags could be:

;[
  {
    @filteredTag: ["description_contains: 'graphql'"],
    id: 'cjsviilj40g8w0b43qntvli9c',
    createdAt: '2019-03-05T08:29:35.483Z',
    updatedAt: '2019-03-05T08:29:35.483Z',
    title: 'GraphQL - The Query Language of the Future',
    published: true,
  },
  {
    @filteredTag: ["description_contains: 'prisma'"],
    id: 'cjsviiljr0g9j0b43vntjbys1',
    createdAt: '2019-03-05T08:29:36.483Z',
    updatedAt: '2019-03-05T08:29:36.483Z',
    title: 'Prisma replaces traditional ORMs',
    published: true,
  },
  {
    @filteredTag: ["description_contains: 'graphql'", "description_contains: 'prisma'"],
    id: 'cjsviiljr0g9j0b43vntjbys3',
    createdAt: '2019-03-05T08:29:36.483Z',
    updatedAt: '2019-03-05T08:29:36.483Z',
    title: 'Prisma and GraphQL are great',
    published: true,
  },
]

Just had another look at this and it seems that deploying this schema clean (i.e. not updating an existing database) also fails with the same message

Hi, we’ve all probably heard about the Log4j vulnerability right now. Prisma 1 seems to be using Log4j which somebody created an issue about here. Can anybody from the Prisma team shed some light on whether Prisma 1 is affected by this vulnerability?

I've started the migration to Prisma 2. Kinda painful. Three problems... First, prisma-migrate's SQL commands aren't recognized. That is, after you run them against the database, prisma-migrate keeps listing them as required. (I did confirm that they successfully ran) Second, when prisma-migrate adjusts the schema.prisma file, it makes an invalid schema. My schema is littered with bugs that takes hours to work through. e.g. duplicate fields, @map and @relation on the same line, etc. And when that's all worked through and I attempt to migrate the db, I get a message stating the database drifted too far and the data needs to be wiped. Has anyone else successfully migrated a large-ish Prisma 1 schema and have any tips or found any of these issues? Thanks!

Hi, I'm having an issue right now. I'm trying to acces to my Prisma Admin tab on app.prisma.io and it just shows the spinner without showing my datas. When I'm trying to run my app I have this error:

"Task slick.basic.BasicBackend$DatabaseDef$$anon$3@42a247f4 rejected from slick.util.AsyncExecutor$$anon$1$$anon$2@53b4c770[Running, pool size = 1, active threads = 0, queued tasks = 1000, completed tasks = 593312]"

Does someone knows what is the problem and can help me to fix the issue ?

Hello, We are trying to link two tables as 

Post

 and 

Category

 via intermediary table named 

PostCategory

, which we’ve renamed for this example:

type Post {
  id: ID! @id
  name: String
  categories: [PostCategory] @relation(name: "PostToPostCategory")
  aliasesOf: [PostCategory] @relation(name: "PostToPostAlias")
  ...
}

type Category {
  id: ID! @id
  name: String!
  posts: [PostCategory!] @relation(name: "CategoryToPostCategory")
  ...
}

type PostCategory {
  id: ID! @id
  post: Post @relation(name: "PostToPostCategory", link: INLINE)
  category: Category @relation(name: "CategoryToPostCategory", link: INLINE)
  aliasOf: Post @relation(name: "PostToPostAlias", link: INLINE)
}

As soon as we add the 

aliasesOf

 relation, which is an additional relation that links a 

Post

 to another 

Post

 of the same 

Category

, we are getting the following error on deploy:

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

It throws this error when we deploy to our existing instance. However, it works fine when we create the Prisma instance from scratch, but, when we add data to that new instance, it throws the same error. We’ve read some other posts that mention this error but none of the examples people were posting mentioned 2 relationship fields in the same intermediary table. Does anyone know what we might be doing wrong?

Hi Mike, I don't think your PostCategory should have those relations inlined. (I forget the exact reason). I have a similar model relationship where a Company type has customers and employees that both reference User types, but our User model doesn't specify the relation as inline.

@lawjolla It is normal to use the INLINE flag on the one-side of a many-to-one relation. Whether it is needed is a different question

My schema disagrees. Perhaps you have a suggestion to help Mike?