kit icon indicating copy to clipboard operation
kit copied to clipboard

Published 20 hours ago • verified publisher icon sveltejs

chore(deps): update all non-major dependencies

Open renovate[bot] opened this issue 1 year ago • 1 comments

Mend Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
@sveltejs/site-kit 5.2.1 -> 5.2.2 age adoption passing confidence
dts-buddy ^0.0.10 -> ^0.1.0 age adoption passing confidence
vitest ^0.31.0 -> ^0.32.0 age adoption passing confidence

Release Notes

sveltejs/site-kit

v5.2.2

Compare Source

Patch Changes
  • a6d1692: monochrome terminal chrome
vitest-dev/vitest

v0.32.2

Compare Source

   🐞 Bug Fixes
    View changes on GitHub

v0.32.1

Compare Source

   🚀 Features
   🐞 Bug Fixes
    View changes on GitHub

v0.32.0

Compare Source

   🚨 Breaking Changes
  • Throw an error, if the module cannot be resolved  -  by @​sheremet-va in https://github.com/vitest-dev/vitest/issues/3307 (1ad63)
    • Vitest used to fall back to the original import when it could not resolve it to the file path or the virtual module. This leads to hard-to-find module graph mismatches if you had incorrect alias or relied on relative imports to be resolved to the project root (which is usual behavior in TypeScript) because the code accidentally "worked". With this release, Vitest will now throw an error if it cannot resolve the module - there are possible edge cases that are not covered yet, so if you have any problems with this, please open a separate issue with reproduction.
  • Improve globs  -  by @​nickmccurdy in https://github.com/vitest-dev/vitest/issues/3392 (19ecc)
    • Vitest now has glob patterns similar to Jest for better compatibility. It's possible that some files will be considered test files when previously they were not. For example, Vitest now considers test.js to be a test file. Also any file in __tests__ is now considered to be a test, not just files with test or spec suffix.
  • Add @vitest/coverage-v8 package  -  by @​AriPerkkio in https://github.com/vitest-dev/vitest/issues/3339 (82112)
    • Vitest now uses v8 code coverage directly for better performance. @vitest/coverage-c8 is deprecated as Vitest no longer uses c8 package for coverage output. It will not be updated anymore, and Vitest will fail in the next version if the user has c8 as their coverage provider. Please, install the new @vitest/coverage-v8 package if you previously used @vitest/coverage-c8.
  • mocker: Don't restore mock to the original if the module is automocked  -  by @​sheremet-va in https://github.com/vitest-dev/vitest/issues/3518 (c1004)
    • spy.mockRestore on auto-mocked named exports will no longer restore their implementation to the actual function. This behavior better matches what Jest does.
   🚀 Features
   🐞 Bug Fixes
    View changes on GitHub

v0.31.4

Compare Source

   🚀 Features
   🐞 Bug Fixes
    View changes on GitHub

v0.31.3

Compare Source

   🚀 Features
   🐞 Bug Fixes
    View changes on GitHub

v0.31.2

Compare Source

   🚀 Features
   🐞 Bug Fixes
    View changes on GitHub

v0.31.1

Compare Source

   🚀 Features
   🐞 Bug Fixes
    View changes on GitHub

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

  • [ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate. View repository job log here.

renovate[bot] avatar Jun 23 '23 22:06 renovate[bot]

Hey @TomasMoskala

You can pass undefined to the fields but pass undefined will omit the field. Please read more about null vs undefined in prisma client here: https://www.prisma.io/docs/concepts/components/prisma-client/null-and-undefined

If this doesn't resolve you problem, please provide an example of the query which is not working for you.

pantharshit00 avatar Jan 29 '21 16:01 pantharshit00

For data it works but not in where clause. This causes an error

    question_id = undefined;
    return ctx.prisma.question.upsert({
      create: newQuest,
      update: newQuest,
      where: {question_id}
    });

This works

    return ctx.prisma.question.upsert({
      create: newQuest,
      update: newQuest,
      where: {question_id: question_id ? question_id : 0}
    });

TomasMoskala avatar Jan 29 '21 16:01 TomasMoskala

Marking as improvement. Maybe we can loosen up the validation for upserts here.

pantharshit00 avatar Feb 03 '21 14:02 pantharshit00

I want to give a big 👍 to this.

Here's my use case:

    const question = await db.question.update({
      where: { id },
      data: {
        ...data,
        choices: {
          upsert: data.choices.map((choice) => ({
            where: { id: choice.id },
            create: { text: choice.text },
            update: { text: choice.text },
          })),
        },
      },
    })

Which produces this error when choice.id is undefined:

Invalid `prisma.question.update()` invocation:

{
  where: {
    id: 3
  },
  data: {
    createdAt: new Date('2021-02-25T17:28:52.806Z'),
    updatedAt: new Date('2021-02-25T17:28:52.806Z'),
    text: 'hi',
    choices: {
      upsert: {
        '0': {
          where: {
?           id?: Int
          },
          create: {
            text: '2'
          },
          update: {
            text: '2'
          }
        }
      }
    }
  }
}

Argument data.choices.upsert.0.where of type ChoiceWhereUniqueInput needs at least one argument. Available args are listed in green.

Note: Lines with ? are optional.

But I can get it to work by changing where: { id: choice.id } to where: { id: choice.id || 0 }

If I have a specific id then 99% of the time that record will exist. It’s id = undefined when I need upsert. So if upsert doesn’t allow undefined, then upsert is useless in this case (unless we do a hack like {where: {id: user.id || 0}})

flybayer avatar Feb 26 '21 15:02 flybayer

Hmm, this is a tricky one because undefined so far has consistently meant exclude from the results.

I agree with @flybayer though that id = undefined is when you need actually want to upsert.

I'm wondering 2 things:

  • Could an upsert with an empty where clause always try to create? This would be consistent with our current approach.
  • Change the where type to not allow undefined since it triggers a validation error anyways. Then the proper way is user.id || 0 or user.id || "".

Any other ideas?

matthewmueller avatar Jan 07 '22 22:01 matthewmueller

Hmm, this is a tricky one because undefined so far has consistently meant exclude from the results.

I agree with @flybayer though that id = undefined is when you need actually want to upsert.

I'm wondering 2 things:

  • Could an upsert with an empty where clause always try to create? This would be consistent with our current approach.
  • Change the where type to not allow undefined since it triggers a validation error anyways. Then the proper way is user.id || 0 or user.id || "".

Any other ideas?

Not a big fan of the first point, if that was the case we should just use update then. I like the second point though.

Just updating the docs would be a valid solution imo., as the example given upsert a user where id = 1, but how often are id's supplied in a create?

const result = await prisma.user.upsert({ 
  where: { id: user.id || 0 }, 
  update: { email: '[email protected]' }, 
  create: { email: '[email protected]' }, 
})

maybe?

Ol1BoT avatar Jan 20 '22 11:01 Ol1BoT

I don't see any problem with the first point. If the ID comes from an user input, then it should be possible to pass undefined. I mean, it's exactly the point of an upsert: "if the id is not provided or the record doesn't exists, create, otherwise update".

ramiel avatar Apr 20 '22 10:04 ramiel

just ran into this, the error is very vague as well

Argument where of type <modelName>WhereUniqueInput needs at least one argument. Available args are listed in green.

...what?

odama626 avatar May 15 '22 16:05 odama626

Hmm, this is a tricky one because undefined so far has consistently meant exclude from the results.

I agree with @flybayer though that id = undefined is when you need actually want to upsert.

I'm wondering 2 things:

  • Could an upsert with an empty where clause always try to create? This would be consistent with our current approach.
  • Change the where type to not allow undefined since it triggers a validation error anyways. Then the proper way is user.id || 0 or user.id || "".

Any other ideas?

Regarding the consistency in the Prisma api that "undefined" translates to "omit this", true, Prisma could just ask the user to only use "undefined" values in this specific way, but this has problems:

  • new users should not be expected to know this and have no good way to learn this rule
  • Prisma can't display an error message when "undefined" values are passed in incorrectly because, technically speaking, it's user error, not an error with Prisma

So from my viewpoint, it might be good to refactor some of the prisma api to let "undefined" simply mean "undefined" and not "omit this value"

Johnrobmiller avatar Jul 09 '22 17:07 Johnrobmiller

Hmm, this is a tricky one because undefined so far has consistently meant exclude from the results. I agree with @flybayer though that id = undefined is when you need actually want to upsert. I'm wondering 2 things:

  • Could an upsert with an empty where clause always try to create? This would be consistent with our current approach.
  • Change the where type to not allow undefined since it triggers a validation error anyways. Then the proper way is user.id || 0 or user.id || "".

Any other ideas?

Regarding the consistency in the Prisma api that "undefined" translates to "omit this", true, Prisma could just ask the user to only use "undefined" values in this specific way, but this has problems:

* new users should not be expected to know this and have no good way to learn this rule

* Prisma can't display an error message when "undefined" values are passed in incorrectly because, technically speaking, it's user error, not an error with Prisma

So from my viewpoint, it might be good to refactor some of the prisma api to let "undefined" simply mean "undefined" and not "omit this value"

I'm running into this issue as well. I have a table with a UUID string as primary key. When I do an upsert on this table, I use a where clause like where: { id: data?.id }. This gives the error stated by the OP when the id is undefined. As a workaround I use where: { id: data.id || ""} but this is technically not correct. An id could be "" when a record was explicitly added with "" as the id. Then the upsert would update that record instead of creating a new one.

I think the comment of @Johnrobmiller is spot on. The definition of "undefined" in a where clause should not be the same as in a create/update object.

As a workaround, maybe you could make a where clause not be required in the upsert method? When the where clause is omitted, then always perform a create. Then we could do something like where: data.id ? { id: data.id } : undefined. Not very user friendly, but at least an alternative.

JWW87 avatar Jul 21 '22 10:07 JWW87

Hmm, this is a tricky one because undefined so far has consistently meant exclude from the results.

I agree with @flybayer though that id = undefined is when you need actually want to upsert.

I'm wondering 2 things:

  • Could an upsert with an empty where clause always try to create? This would be consistent with our current approach.
  • Change the where type to not allow undefined since it triggers a validation error anyways. Then the proper way is user.id || 0 or user.id || "".

Any other ideas?

I strongly agree with and prefer option 1

I think a common usecase for upsert (for me anyway) is for an array of records to be either created or updated and they may or may not already exist in the table.

Below is an example of the API that I prefer the most but currently results in a runtime error because charge.id may be undefined.

interface Charges {
    id?: number;
    accountID: number
    amount: number;
}

const charges: Charges[] = [...]

prisma.accounts.update({
    where: { id: myAccount.id },
    data: {
        charges: {
            upsert: charges.map((charge) => ({
                where: { id: charge.id }, // Runtime error because charge.id may be undefined
                update: { ...charge },
                create: { ...charge },
            })
        }
    }
})

As an alternative, option 2 could at least remove the runtime error and prevent this passing the type check which would still be an improvement on the API.

This just feels unnecessary: where: { id: charge.id ?? -1 },

Chris112 avatar Aug 20 '22 08:08 Chris112

I just wanted to chime in for option 1.

I ran into this issue when using UUIDs as id:

await prisma.model.upsert({
    where: { id: modelId || '' },
    update: data,
    create: data,
  })
// > Inconsistent column data: Error creating UUID, invalid length: expected length 32 for simple format, found 0

where: { id: modelId || 0 } and where: { id: modelId || null } give type errors as expected. Using the zero UUID works: where: { id: organizationId || '00000000-0000-0000-0000-000000000000' }, but thats rather awkward and defies the use of an upsert, right?

My expectation as Prisma user is that id: undefined should work.

ohueter avatar Mar 10 '23 13:03 ohueter

For data it works but not in where clause. This causes an error

    question_id = undefined;
    return ctx.prisma.question.upsert({
      create: newQuest,
      update: newQuest,
      where: {question_id}
    });

This works

    return ctx.prisma.question.upsert({
      create: newQuest,
      update: newQuest,
      where: {question_id: question_id ? question_id : 0}
    });

Works like a charm... Thanksss!

lesimoes avatar Mar 18 '23 15:03 lesimoes

I would like to see the undefined approach also

altarrok avatar Apr 07 '23 05:04 altarrok

+1 to making the where property optional on the upsert options and doing a create if it is not passed... as mentioned earlier, this issue is particularly annoying if you use UUID primary keys

emiller12 avatar Apr 18 '23 05:04 emiller12

So, I'm replying again to say that right now upsert is not working with MongoDB and there's no workaround. As @ohueter is pointing out, you have to pass a valid value and in case of MongoDB it must be an ObjectId. I really think this is not a secondary issue and it should be addressed since a core API is completely not working. Even if I'd like to see the undefined option to be implemented, I'd appreciate anything that works. I'd also provide a PR as soon as a design decision is taken

ramiel avatar May 23 '23 09:05 ramiel

If something does not work @ramiel, especially specific to one provider/database, we should have a bug issue that provides the information that allows us to reproduce, understand and debug it. This here is an improvement request (and your message that mentions MongoDB in that context), and as such of course does not get the same priority. Please open one. Thanks.

janpio avatar Jun 06 '23 10:06 janpio

Of course @janpio , thank you. I moved on but when I'll have time I'll open a new issue

ramiel avatar Jun 06 '23 11:06 ramiel

I am having the same issue as others, where it would be useful to be able to have a where UUIDs are undefined, and create on this condition.

Since this is not an option I am having to do similar to @ohueter 's solution and pass in a valid UUID as '00000000-0000-0000-0000-000000000000' which I know (hope?) won't be found.

DanStevensonDev avatar Jun 22 '23 11:06 DanStevensonDev

@DanStevensonDev yep I imagine a few of us have the same dirty little hard coded 00000000-0000-0000-0000-000000000000 in our code because of this oddity in the way prisma upsert works.

As you say, simple solution would be to allow undefined and just do a "create" if there is no where clause.

emiller12 avatar Jun 22 '23 22:06 emiller12

By giving a random uuid you can also get rid of type errors and possible unexpected updates.

import { randomUUID } from 'node:crypto'

await prisma.model.upsert({
    where: { id: modelId || randomUUID() },
    update: data,
    create: data,
  })

melihkizmaz avatar Oct 04 '23 14:10 melihkizmaz

@melihkizmaz by doing so you are introducing a non-zero probability of operation failure, no matter how small the probability is, you are now responsible for handling that failure case. Which is going to be nasty to deal with.

We need real solution, not some hack to get around it, Prisma needs to keep up with these requests, we are not asking for much here.

altarrok avatar Oct 04 '23 14:10 altarrok

I think this solution is also wrong because if for some reason the internal implementation changes, that value can end up being the ObjectID for the creation resulting in a failure on MongoDB

ramiel avatar Oct 04 '23 15:10 ramiel

Hmm, this is a tricky one because undefined so far has consistently meant exclude from the results.

I agree with @flybayer though that id = undefined is when you need actually want to upsert.

I'm wondering 2 things:

  • Could an upsert with an empty where clause always try to create? This would be consistent with our current approach.
  • Change the where type to not allow undefined since it triggers a validation error anyways. Then the proper way is user.id || 0 or user.id || "".

Any other ideas?

I like the first option too. Way more intuitive given Prisma global philosophy

martialanouman avatar Oct 04 '23 16:10 martialanouman

@melihkizmaz by doing so you are introducing a non-zero probability of operation failure, no matter how small the probability is, you are now responsible for handling that failure case. Which is going to be nasty to deal with.

We need real solution, not some hack to get around it, Prisma needs to keep up with these requests, we are not asking for much here.

I know that this is a work around, I apologize for pretending to offer a solution, I just made an extra suggestion instead of a usage like '00000000-0000-0000-0000-0000-000000000000' (the same non-zero probability is here) but I could not express it correctly.

I agree that we need a real solution by Prisma.

melihkizmaz avatar Oct 05 '23 06:10 melihkizmaz

I just ran into this and, honestly, would like to be able to just create an entry on the DB if the where clause on the upsert is undefined. I see how this could be a problem for new users. Maybe if the upsert operation had a strict mode, enabled by default, we could just have an option like { strict: false } to allow the upsert to create an entry if the where clause is undefined, that would be really useful.

ferrbruno avatar Oct 19 '23 15:10 ferrbruno

no solution to this?

CamiloERH avatar Jan 26 '24 00:01 CamiloERH

@melihkizmaz by doing so you are introducing a non-zero probability of operation failure, no matter how small the probability is, you are now responsible for handling that failure case. Which is going to be nasty to deal with.

We need real solution, not some hack to get around it, Prisma needs to keep up with these requests, we are not asking for much here.

Lets be real here, the odds of uuids colliding is ridiculously low (1 in a billion if you have 103 TRILLION of them). Agree it would be nice if Prisma allowed this as it's also the intuitive behavior I'd expect but the workaround is about as pain free as it gets.

riley-worthington avatar Feb 12 '24 05:02 riley-worthington

@melihkizmaz by doing so you are introducing a non-zero probability of operation failure, no matter how small the probability is, you are now responsible for handling that failure case. Which is going to be nasty to deal with. We need real solution, not some hack to get around it, Prisma needs to keep up with these requests, we are not asking for much here.

Lets be real here, the odds of uuids colliding is ridiculously low (1 in a billion if you have 103 TRILLION of them). Agree it would be nice if Prisma allowed this as it's also the intuitive behavior I'd expect but the workaround is about as pain free as it gets.

Even though that's a wikipedia page you linked, I agree with your point, it is pretty much a pain-free workaround. My message is to Prisma, I still have the same issues that I had when I started using Prisma, which is about 3-4 years now. As I stated, we need a real solution for problems like these because ultimately, it is crucial to advocate for the enhancement of the quality of the libraries we use.

altarrok avatar Feb 12 '24 06:02 altarrok