liesislukas Github contribution chart
liesislukas Github Stats
liesislukas Most Used Languages


10 Sep 2022

Issue Comment


chokidar firing twice

I moved from to chokidar because of multi-calls But chokidar also firing twice even in simplest scenario:'change', (event, path) => {
      console.log(event, path);

How can I make sure chokidar fires only once?


chokidar:  1.7.0
Node v7.10.0
MacOS Sierra 10.12.3 


Forked On 10 Sep 2022 at 03:00:47


 awaitWriteFinish: {
        stabilityThreshold: 2000,
        pollInterval: 100,

just delays double event by some time for me. tracking changes by IntelliJ WebStorm. WebStorm is doing some magic on it's own for sure when it comes to file writes so probably that's related.

Commented On 10 Sep 2022 at 03:00:47
Issue Comment


Be able to update or retrieve a single record including non-unique fields in the "where" conditions.


I am unable to utilize non-unique fields in single update queries. To be clear, I want to still use the unique fields, I just want to filter it down even more.

Suggested solution

Here are my models

model Person {
  id     String   @id @db.Uuid
  client Client[]

model Client {
  id       String @id @db.Uuid
  name     String
  personId String @db.Uuid
  person   Person @relation(fields: [personId], references: [id])

I have "people" who have "clients" attached to them. Only the person who owns the client can update the name. So when an API call comes in, I know who the current person is and what client they're trying to update. So the update query I would like to use is this:

const client = await prisma.client.update({
  data: { name: },
  where: {
    id: input.clientId,
    personId: input.personId

but it only allows fields which are marked as @unique or @id


One alternative is to do a .findUnique({ where: { id: input.clientId } }) and then check if the personId of the client is the same as the one passed in. This however creates two database calls where only one is needed.

Another alternative is to do a .updateMany({ where: { id: input.clientId, personId: input.personId } }) but I don't get any of the clients back. If I got the clients back in the query and if there was a limit I could pass in to limit it to one, I would feel better about this so it wouldn't have to do any unneeded scans of the rows, but it still feels less idiomatic than updating the .update() command to allow for non-unique fields.

Forked On 06 Sep 2022 at 08:19:41



dynamodb has same issue and resolve it with ConditionExpression in update call. Adding sample query. Maybe something to think about. Edited query here inline, hope no types, but idea should be clear, check docs for more details.

related dynamo docs:

 await db
        TableName: "some_table",
        Key: {
          authCode: req.body.code,
          "attribute_not_exists(consumedAt) and #clientApplicationId = :clientApplicationId and #expiresAt > :now ",
          "set #consumedAt = :now",
        ExpressionAttributeNames: {
          "#clientApplicationId": "clientApplicationId",
          "#expiresAt": "expiresAt",
        ExpressionAttributeValues: {
          ":clientApplicationId": req.body.client_id,

Commented On 06 Sep 2022 at 08:19:41
Issue Comment


s3.putBucketLifecycleConfiguration, Filter not marked as required in docs

in the docs for putBucketLifecycleConfiguration there are a number of params fields marked as required, but Filter is not.

If you don't have a Filter on a rule, you get a misleading error:

MalformedXML: The XML you provided was not well-formed or did not validate against our published schema

There's no XML here, it's JSON. The JSON is well-formed and there's no current, valid, correct, and published schema to check against.

In order to get past that MalformedXML error, all you have to do is add the Filter param with an empty Prefix:

 const params = {
    LifecycleConfiguration: {
      Rules: [{
        ID: 'Expire objects older than 15 days',
        Status: 'Enabled',
        Expiration: {
          Days: expirationDays,
        // this object is REQUIRED in a rule otherwise you trigger a MalformedXML error:
        Filter: {
          Prefix: '',

Forked On 01 Sep 2022 at 08:23:55


FYI, just ran into this issue. Filter is optional in general docs, it's optional in typescript declaration in aws v2 sdk too yet it's not optional like it's described in this issue.



Only place where it mentions about required is in sdk docs but it's a bit tricky too, while it's optional when Prefix is set but Prefix is no longer in use, so it is not optional.


Commented On 01 Sep 2022 at 08:23:55



Started On 01 Sep 2022 at 05:49:02
Issue Comment


Prettier plugin for .prisma files

Since the prisma schema has defined file formatting guidelines, a prettier plugin should exist so we can format .prisma files using our CI system along with all our other files.

Currently there's a VS Code extension to do this, but tons of people including myself don't use VS Code. Additional, this extension can't be used with CI and git hooks.

From #1557

Forked On 10 Aug 2022 at 02:57:00


I have schema code built by other tools i build and in this use case i want to have a function where i can provide generated code and get nice formatted schema to write to schema file.

This worked fine, yet npm package is deprecated

 const { formatSchema } = require("@prisma/sdk");
  content = await formatSchema({schema: content}); 

I tried @umidbekk plugin but it failed to do the job with error which seem like prettier is looking like prettier thinks it's javascript, while it's not. And i don't see any way to tell prettier that it's prisma schema. Any hints?

 let result = prettier.format(code, {
      parser: "babel", plugins: ["prettier-plugin-prisma"]


Commented On 10 Aug 2022 at 02:57:00


Next-generation ORM for Node.js & TypeScript | PostgreSQL, MySQL, MariaDB, SQL Server, SQLite, MongoDB and CockroachDB

Forked On 07 Aug 2022 at 09:54:26
Issue Comment


Virtual fields

Virtual or computed fields can be pretty useful when fields are derived from the parts of the actual record(for example computing gravatar from email).

Mongoose implements them like so:

Rough Proposal

Firstly, we can have @computed fields in our schema.

model User {
  id String @id @default(cuid())
  email String
  gravatar String @computed

Now what cli will do is to generate a computed folder inside the prisma folder with the files for each model:

    └── computed
        ├── Post.ts
        └── User.ts 

In each file we can have generated skeleton code for the computed fields so that we can implement them:


// Implement computed fields for User.ts model

export const gravatar = photon.user.computed(record => {
	const hash = md5(;
	return `${hash}`

Photon would use these methods in the generated code.

Forked On 07 Aug 2022 at 09:45:31


in my use case i want to have prefix for all IDs, so i could tell from ID itself what data model is it. Looking for ways to implement this.

model User {
  id String @id @default(cuid('u-')) // <--- this would make cuid but with prefix "u-"
  email String
  gravatar String @computed

Commented On 07 Aug 2022 at 09:45:31



Pushed On 06 Jul 2022 at 04:02:50