After generating the client, is the prisma.schema file needed at runtime? I would have guessed no but I'm seeing some error that looks like during instantiation it tries reading it

where does it look for the file?

it's odd because it looks like it copies it into the generated client directory but then doesn't use that at runtime and instead looks for it in parent directory?

is this a bug? how can I get it to use the schema it copies into generated client directory?

Is it just me or the interactive transactions doesn’t log DB queries? All I see is

BEGIN

and nothing more.

How would you go about modeling this in a Schema?

model Dish {
...
}

model Plan {
  ...
  monday Dish[]
  tuesday Dish[]
  wednesday Dish[]
  thursday Dish[]
  ...
}

Hi Everyone, Please I need help seeding my database. 1. * Country: 250 ✅ 2. * State: 4,888 ❌ 3. * City: 20,000 ❌

const countries = await prisma.locationCountry.createMany({
    data: countryArray,
    skipDuplicates: true,
  });

Country has 250 records and it loads well. States and Cities record break along the line. Is there a limit to records that can be seeded in Nestjs + Prisma ?

is it possible to do a

groupBy

with

_count: {distinct: {foo: true}}

? would like to group by DISTINCT someColumn

Hello! how to run prisma client inside nextjs edge function?

Ran into a severe performance issue yesterday. I have a model like

model User {
  id           Int      @id @default(autoincrement())
  primaryEmail String   @unique @map("primary_email")
  emails        Email[]
  @@map("users")
}

model Email {
  id                 Int      @id @default(autoincrement())
  userId             Int      @map("user_id")
  user               User     @relation(fields: [userId], references: [id])
  email              String   @unique
  @@map("emails")
}

And I'd like to get all users who don't have an email, per the docs, I'm running:

prisma.user.findMany({
  where: { emails: { none: {} } }
});

This creates SQL along the lines of:

SELECT * FROM users
WHERE (users.id) NOT IN (
    SELECT users.id
    FROM users
    INNER JOIN emails
        ON (emails.user_id) = (users.id)
    WHERE (users.id IS NOT NULL)
)

The query plan for this

EXPLAIN SELECT * FROM users
WHERE (users.id) NOT IN (
    SELECT users.id
    FROM users
    INNER JOIN emails
        ON (emails.user_id) = (users.id)
    WHERE (users.id IS NOT NULL)
);
                                          QUERY PLAN
----------------------------------------------------------------------------------------------
 Seq Scan on users  (cost=2057.26..59509346.61 rows=24028 width=26)
   Filter: (NOT (SubPlan 1))
   SubPlan 1
     ->  Materialize  (cost=2057.26..4394.34 rows=55777 width=4)
           ->  Hash Join  (cost=2057.26..3897.46 rows=55777 width=4)
                 Hash Cond: (emails.user_id = users_1.id)
                 ->  Seq Scan on emails  (cost=0.00..1069.77 rows=55777 width=4)
                 ->  Hash  (cost=1268.56..1268.56 rows=48056 width=4)
                       ->  Seq Scan on users users_1  (cost=0.00..1268.56 rows=48056 width=4)
                             Filter: (id IS NOT NULL)
(10 rows)

is prohibitively expensive to run because it materializes a table of all users who have emails and then scans it for each row in users. Our users table is relatively small (~52,000 rows) but these queries take forever (i.e. they don't terminate) and started clogging up our db connection pool. I can write a handwritten query that joins a table of all users without an email that runs almost instantly. I'm wondering if there is an explanation for this behavior so I can understand and avoid it in the future, or if this is sub-optimal performance that could be fixed with a PR?

If this is a bug I will create a github issue, but honestly I'm not sure if it's a bug or I'm just misunderstanding something

Hi, having random trouble running / building prisma with UBI8-node (builder container). Sometimes it fails with:

#15 1.154 ==[ @xxx/some-module ]======================================[ 3 of 11 ]==
#15 5.338 "@xxx/some-module" completed successfully in 4.25 seconds.
#15 5.338 Error: Unable to require(`/build/common/temp/node_modules/.pnpm/prisma@3.7.0/node_modules/prisma/libquery_engine-rhel-openssl-1.1.x.so.node`)
#15 5.338  /build/common/temp/node_modules/.pnpm/prisma@3.7.0/node_modules/prisma/libquery_engine-rhel-openssl-1.1.x.so.node: ELF load command past end of file

This seem to happen randomly, and in different modules requiring prisma.

bash-4.4#  /build/common/temp/node_modules/.bin/prisma2 -v
prisma                  : 3.7.0
@prisma/client          : 3.7.0
Current platform        : rhel-openssl-1.1.x
Query Engine (Node-API) : libquery-engine 8746e055198f517658c08a0c426c7eec87f5a85f (at common/temp/node_modules/.pnpm/@prisma+engines@3.7.0-31.8746e055198f517658c08a0c426c7eec87f5a85f/node_modules/@prisma/engines/libquery_engine-rhel-openssl-1.1.x.so.node)
Migration Engine        : migration-engine-cli 8746e055198f517658c08a0c426c7eec87f5a85f (at common/temp/node_modules/.pnpm/@prisma+engines@3.7.0-31.8746e055198f517658c08a0c426c7eec87f5a85f/node_modules/@prisma/engines/migration-engine-rhel-openssl-1.1.x)
Introspection Engine    : introspection-core 8746e055198f517658c08a0c426c7eec87f5a85f (at common/temp/node_modules/.pnpm/@prisma+engines@3.7.0-31.8746e055198f517658c08a0c426c7eec87f5a85f/node_modules/@prisma/engines/introspection-engine-rhel-openssl-1.1.x)
Format Binary           : prisma-fmt 8746e055198f517658c08a0c426c7eec87f5a85f (at common/temp/node_modules/.pnpm/@prisma+engines@3.7.0-31.8746e055198f517658c08a0c426c7eec87f5a85f/node_modules/@prisma/engines/prisma-fmt-rhel-openssl-1.1.x)
Default Engines Hash    : 8746e055198f517658c08a0c426c7eec87f5a85f
Studio                  : 0.445.0

I also saw a “Bus error” (SIGBUS from memory access error?) from prisma-engine twice yesterday, but haven’t been able to reproduce that today. Anybody experienced this (what can cause this)?

Hey all! I’m getting this behavior when trying to query prisma in a

next.js

middleware page. Has anyone encountered this before?

Hello #mongodb #prisma-client Please what's the current solution to this problem: Error parsing attribute "@default": The function

auto

is not a known function. #11771 https://github.com/prisma/prisma/issues/11771

Hello, I've got an issue with transactions I don't know how to pinpoint. I basically compare 2 sets of data (outside of transaction), and spit out 3 groups of data - entities to update, entities to delete and to create.. In order to maintain some kind of consistency between previous and new data, I'Ve decided to put them in interactive transaction, like so

await prisma.$transaction(async (prisma) => {
  for (const entity of changed) {
    await prisma.entity.update({
      where: ...
      data: ...
    })
  }
  if (deleted.length) {
  	// soft delete
    await prisma.entity.updateMany({
      where: ...,
      data: {
        deleted: true,
      }
    })
  }
  if (created.length) {
    await prisma.entity.createMany({
      data: created,
    })
  }
  logResult(...)
})

The transaction itself works (it's used this way in many different entities and they pass alright), but in a few that seem to run much longer than other, I'm getting an exception:

PrismaClientKnownRequestError: Transaction API error: Transaction already closed: Transaction is no longer valid. Last state: 'Expired'.

What can I do about it, or what causes it?

👋 I'm just getting started with Prisma, and trying to write a seed script. When I try the following, I receive an error that

createMany

does not exist. Anyone know what might be the issue there?

const providers = await prisma.provider.createMany({
  data: [
    { name: "Twitter" },
    { name: "Github" },
    { name: "YouTube" }
  ]
});

Hello, I’m trying to use Prisma with an existing database, but I’m finding that the

@map

doesn’t work for enums? Is this a known limitation? I have a enum defined as

enum DriverStatus {
  OnDuty    @map("ON_DUTY")
  OffDuty   @map("OFF_DUTY")
  Disabled  @map("DISABLED")

  @@map("driver_status_enum")
}

But the generated typescript enum is

export const DriverStatus: {
  OnDuty: 'OnDuty',
  OffDuty: 'OffDuty',
  Disabled: 'Disabled'
};

I would expect it to be

export const DriverStatus: {
  OnDuty: 'ON_DUTY',
  OffDuty: 'OFF_DUTY',
  Disabled: 'DISABLED'
};

I'm running into an issue trying to "upsert many" records. I have an

Activity

model, that has a relation field to

Provider

. I'm stuck at the very beginning trying this:

const stars = await getActivity();
await prisma.activity.upsert({
  where: {
    providerId: 2
  }
});

Question about integrating some business logic like sending an email, taking a screenshot with puppeteer, accepting a stripe payment etc... Would the right tool to implement that in reaction to a data write be the

middleware

? https://www.prisma.io/docs/concepts/components/prisma-client/middleware Sounds like the perfect thing to integrate 3rd party APIs before/after a DB operation.

Any ideas about how to shrink the DMMF object? It's way way too big and causing serious performance issues for people. For example: what if we assume

"dbName"

is

null

if it's not defined, or

isReadOnly

is

false

if not defined,

isNullable

is

false

if not specified, etc I have a modest DB schema and my DMMF string is like 7MB. I believe it would be able to get it a lot smaller if we assume missing values are `false`/`null`. Is this a possibility? I'm willing to open a PR I just need a little guidance on this. My job is to make my application go faster and this appears to be at least one of the bottlenecks. More details are in that issue I linked.

Related: why do we emit a dmmfString and then parse it in the generated client? Can we just emit the dmmf JSON directly?

I want to test my changes to the prisma engine when generating the nodejs client. I ran

cargo build

in

prisma-engines

- do I need to specify my locally built library in

PRISMA_QUERY_ENGINE_LIBRARY

when running

npx prisma generate

? If I pass in the query engine dylib that got built:

[db:generate] Error: Unable to require(`/Users/cyber/dev/prisma-engines/target/debug/libquery_engine.dylib`)
[db:generate]  Invalid or unexpected token
[db:generate] npm ERR! Lifecycle script `generate` failed with error:

I want to test my changes to DMMF generation locally and am not clear on how to do this

How would I use

createMany

with a set of data that may have duplicates in the db (based on two non-@id fields)

Hi all, i am facing weird connexion timeout problems with prisma and prisma-client and my CI, maybe you can help: • When using prisma transactions with postgresql on our ApolloServer, i end up with prisma closing his connexions with the database (drop from 3 to 1) and does not recover (no more scale up to 3) leading to query “stuck” issues when two concurrent requests try to get a connexion each. • I haven’t been able to reproduce this “dangling state” manually even by force closing connexions. when we watch it, prisma always recover the proper amount of transactions. • It always occurs on production/CI after the server running for some time on any query that next multiple connexions I’m looking for ideas to dig further into this issue. Thanks a lot for your help !

How can I view a record's original data during an interactive transaction?

prisma.$transaction(async (prisma) => {
  const user = await prisma.user.update({
    where: {
      id: 1,
    },
    data: {
      name: 'Bob'
    },
  });

  // How can I view the user's original name before the current update?

  return user;
});

Hello prisma crew. I’m in a situation where I need to process and update a table with 100k+ records - it’s going to take awhile running each update one at a time. Each update is unique.

updateMany

really only seems to handle one data change on multiple records. What I really need is something like

createMany

, where you can prep lots of updates for many records, then execute them all at once. I take it the only real option to speed things up is batching inside of a transaction? In sets of like 10 or so?

await prisma.$transaction([
  prisma.table.update({ where: { id: id1 }, data: { field: field1 }),
  prisma.table.update({ where: { id: id2 }, data: { field: field2 }),
  prisma.table.update({ where: { id: id3 }, data: { field: field3 }),
  ...
])

hi is there planned support for the

cidr

data type anytime soon

?