Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make requests case insensitive #79

Open
jaaneh opened this issue Dec 7, 2022 · 6 comments
Open

Make requests case insensitive #79

jaaneh opened this issue Dec 7, 2022 · 6 comments
Assignees
Labels
bug Something isn't working enhancement New feature or request

Comments

@jaaneh
Copy link
Collaborator

jaaneh commented Dec 7, 2022

For example, making a request to get a profile with the name Jan will not return the profile of an existing user with name jan. Seeing as emails and usernames are unique, we should make these case insensitive.

@jaaneh jaaneh added bug Something isn't working enhancement New feature or request labels Dec 7, 2022
@jaaneh jaaneh self-assigned this Dec 7, 2022
@jaaneh
Copy link
Collaborator Author

jaaneh commented Dec 9, 2022

This may be a tad harder than initially thought. While Prisma with PostgreSQL does support case insensitive queries, they have to be enabled on a per-query basis.

await prisma.users.findFirst({
  where: {
    equals: name,
    mode: "insensitive"
  }
})

It does not look like the findUnique() method supports this, as the where query it expects can only be one of the properties of the model and can't include any other inputs or filters.

To properly support this we'll need to switch all of our instances of findUnique() to findFirst() but not sure if there are other caveats to this. Could we for example get a return value we didn't expect with findFirst()?

PostgreSQL requires this to be set per field you query for.

@jaaneh
Copy link
Collaborator Author

jaaneh commented Dec 9, 2022

@Fermain Any thoughts on this? I can't really find any downsides to switching to findFirst, as long as we use equals and not something like contains where it may return incorrect result. I may be missing something though.

@Fermain
Copy link
Contributor

Fermain commented Dec 9, 2022

I'm not sure about the use case. If you're searching for a username shouldn't you be precise?

@jaaneh
Copy link
Collaborator Author

jaaneh commented Dec 9, 2022

I'm not sure about the use case. If you're searching for a username shouldn't you be precise?

Sure, but shouldn't also jAn return the profile for jan when the username is unique?

@jaaneh
Copy link
Collaborator Author

jaaneh commented Dec 9, 2022

Or when logging in, and trying your email with a capital letter at the start

@Fermain
Copy link
Contributor

Fermain commented Dec 9, 2022

If they are unique case insensitive, then yeah, the API should be insensitive too. Email is always insensitive so that makes sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants