https://www.prisma.io/ logo
Join Slack
Powered by
Hi, can someone please help me with this error: ``...
# orm-help
i
Hi, can someone please help me with this error:
Copy code
Argument where of type AccountWhereUniqueInput needs exactly one argument, but you provided id and authorization. Please choose one. Available args:
I don't know how to fix it
j
You need to provide a unique input for the method it seems, not 2.
i
What does that mean? How do I disable it
j
Is this about the 
account
queries you posted above?
What does your 
account
model look like?
i
It looks like this:
Copy code
model Account {
  id Int @default(autoincrement()) @id
  username String @unique @db.VarChar(35)
  email String @unique @db.VarChar(75)
  password String @db.VarChar(100)
  authorization String @unique @db.VarChar(100)
  ip String @default("127.0.0.1") @db.VarChar(150)
  type Int @default(1)

  @@map("accounts")
}
And the error:
Copy code
Argument where of type AccountWhereUniqueInput needs exactly one argument, but you provided id and authorization. Please choose one. Available args:
type AccountWhereUniqueInput {
  id?: Int
  username?: String
  email?: String
  authorization?: String
}
j
For which query is that?
i
For this:
Copy code
await prisma.account
  .findFirst({
    where: {
      id: user.id,
      authorization: user.authorization,
    },
  })
I don't understand why I can only pass one argument for where
j
Hmm, I can run this query just fine with this model:
Copy code
const user1 = await prisma.account.findFirst({
      where: {
          id: 1,
          authorization: "foo"
      }
  })
  console.log(user1)
Same for
Copy code
const user1 = await prisma.account.findMany({
      where: {
          id: 1,
          authorization: "foo"
      }
  })
  console.log(user1)
i
It turns out the error was inside the 
then
and the problem is this code:
Copy code
await prisma.account
  .delete({
    where: {
      id: user.id,
      authorization: user.authorization,
    },
  })
  .then(() => {
    req.session.destroy();
    addResponse(false, null, "Account deleted.");
    res.status(200).json(response);
  })
  .catch(() => {
    addResponse(true, "Query failed, please try again.");
    res.status(200).json(response);
  });
.delete
j
Delete probably needs a specific unique identifier?
i
whats that
deleteMany seems to work
idk why tho
j
Because 
delete
needs to uniquely identify a database entry
And your database does not guarantee that technically
i
oh
so the correct way is to use deleteMany or is there another solution?
j
You can probably just add a unique index over these two fields: 
@@unique([id, authorization])
Then the type will include the combination of these.
(Yep, that is also pretty unintuitive to me coming from plain SQL - but it does make sense from a type perspective)
i
alright, ill just go with deleteMany it seems better
👍 1
s
Hey @janpio, so, does this mean it isn't possible to apply additional filters (where clauses) when using findUnique, update and the like?
j
No, because that way you can not guarantee the uniqueness in the data - you need the unique index for that.
s
Let's say I provide the id, which would guarantee the uniqueness. And additionally I would like to add filters on top of that.
j
What use would the additional filters be then?
s
Don't know, maybe there is some kind of "Soft-Delete-Strategy" in place or an update is only "allowed" if the version hasn't changed
j
That could be a viable use case.
s
Ok, but is it possible right now?
j
No, if you use one of the CLient queries that takes a unique type to find things, then it only takes these.
You can always use the 
many
methods that are not limited to 1 entry being affected.
s
But it would kind of be a workaround, right? Because I know that it is one entry beeing affected
j
Yes but that is the API definition of these methods: "You know it is 1 as you supply exactly that unique identifier"
If you want to do something else, use the other method and have the same knowledge that it will only affect 1 as you supply the unique identifier there as well
s
Yeah, but the 
many
methods do not return the affected "entities". So I would have to do an additional query. No worries. Thanks for your help @janpio
j
Yeah this is a valid argument indeed.
There might be a gap in the API here that is worth that feature request issue 😄
s
Is there already an issue open or do you think we should create a feature request 🙂
j
I could fine none that explains it clearly, so a new one would be nice.
Especially with the use case.
Hmm, this one might be close maybe? https://github.com/prisma/prisma/issues/7290
s
Hey @janpio, yeah, that seems about right. I added a comment to the issue
👍 1
2 Views
Open in Slack
PreviousNext
Powered by