Is there a way to do this yet?

We need this feature as well. Is there any workaround for now?

We need this feature as well. Any plan to add this feature?

We need this as well, anything in the near future planned?

How is this feature not implemented yet? Its crucial in some applications.

This feature would be very neat to have. For string_contains and the other string ones. The array ones too ideally

for MySQL, following this...: https://stackoverflow.com/a/59000485/694133 I tested it manually and it worked successfully... I will research how to implement it and try to submit a PR. But if someone can get it sooner that would be great :)

Any updates on this feature??

Hi, I would like to request this feature as well or understand a workaround if anyone has one.

Would love this feature as well.

Bump on this

I would love this feature as well!

Totally waiting for this feature too!

It would be great to have indeed.

It's quite surprising seeing something like this left out. As bad as "bumps" are, I don't see a single contributor-made comment here and the issue has existed for almost two years.

I am a maintainer here. We are aware this issue exists and we added labels to it to reflect that we understood it. When we have capacity and this gets enough priority among all our issues, we might implement it in the future. No more bumps necessary unless they add new information or additional use cases. Thank you.

Is there any workaround?

Hello, Does anyone have work around on this one?

No more bumps necessary unless they add new information or additional use cases.

The use case we have is that we're storing email addresses as JSON so that they can include name, i.e. {"name": "Foo Bar", "address": "[email protected]"}. For inbound emails, we need to match with a contact for association and since email RFC states that addresses are case-insensitive, we're not able to get a match using Prisma when the address has characters with different casing.

Looks like we'll end up converting all addresses to lowercase before saving to database but that does mean we're making a change to the user data which we'd have preferred not to do even if it's essentially the same from definition point of view.

help us please

We also have a use case, though maybe theres a better option out there for us? We have some data stored in JSON that a user can search for. e.g.

{
    name: "John Doe",
    position: "Software Engineer"
}

Our users may want to search for "engineer", but nothing would show up without specifically searching for "Engineer".

In the mean time our work around is to try search for the original value, the lower case version, the upper case version and the capitalised version. This isn't perfect but hits most of our searches pretty well

{
	OR: [
		{
			data: {
				path: [filter],
				string_contains: value,
			},
		},
		{
			data: {
				path: [filter],
				string_contains: value.toLowerCase(),
			},
		},
		{
			data: {
				path: [filter],
				string_contains: value.toUpperCase(),
			},
		},
		{
			data: {
				path: [filter],
				string_contains:
					value.toLowerCase().charAt(0).toUpperCase() +
					value.slice(1),
			},
		},
	],
}

If theres something else we could do for our use case please let me know

i'd also love this. searching on an open body in a json field property is tricky and needs to be case insensitive

Need this ASAP, any updates or work around ?

Need this ASAP, any updates or work around ?

Have you tried to keep lowercased copy in another column and match them by id?

Need this ASAP, any updates or work around ?

Have you tried to keep lowercased copy in another column and match them by id?

Yeah, that's what I did. but it's still an ugly solution. but it works for the time being.

We also have a use case, though maybe theres a better option out there for us? We have some data stored in JSON that a user can search for. e.g.

Thank you @spencer-robertson ! This was very helpful to us, as this covers the vast majority of our cases in the mean time without requiring data-side hacks. It seems there is a small cost in performance, but it seems worth it.

If anyone else would find this useful, I created a utility to make this method easier to use as needed

const JsonMultiCaseQuery = (path: string[], string_contains: string, jsonProperty: string): {OR: Prisma.Enumerable<{[x: string]: Prisma.JsonFilter}>} => ({
  OR: [
    // as TypEd
		{
			[jsonProperty]: {
				path,
				string_contains,
			},
		},
    // lower case
		{
			[jsonProperty]: {
				path,
				string_contains: string_contains.toLowerCase(),
			},
		},
    // UPPER CASE
		{
			[jsonProperty]: {
				path,
				string_contains: string_contains.toUpperCase(),
			},
		},
    // Capitalized
		{
			[jsonProperty]: {
				path,
				string_contains:
					string_contains.charAt(0).toUpperCase() +
					string_contains.toLowerCase().slice(1),
			},
		},
	],
});

If anyone has suggestions on better typing, I'd welcome feedback. Prisma is new to me and I wanted to avoid typing this specifically for a given model or schema with generated types. I tried generic jsonProperty: T and keying with a mapped type [x in T], but ran into some issues, so went with a string for simplicity for now.

we need this feature. please do it :)

Bump

+1 forced to use raw query 😔

This issue is over 3 years old.
I have tested JSON search and it's still case sensitive (Prisma v5.17.0)
Any news on when this issue might get fixed?

The fix should just add LOWER in the JSON comparison

((JSON_UNQUOTE(LOWER(JSON_EXTRACT(db.table.jsoncol, "$.path"))) LIKE LOWER("%term%")

My (rather ugly) work-around is a separate JSON column all lowercase just for search.

Hello! I wanted to understand where this stands. I've been following the PR but it seems like its gone quiet for over two months. Are there still plans to resolve the issue with the linked PR?

Still not an update for this simple feature?, whoa

Hi. We need this feature too.

P.s. I see it's been ~3.5 years since this thread opened, wow )