Query documents with multiple custom field values

Hello !
I would like to know if it was possible to use the GraphQl API to query multiple documents using a custom field the same way I query multiple documents with id_in ?

This is the equivalent of what I want to achieve with the rest API:
q=[[any(my.employee.job-title,["Developer","Designer"])]]

Thank you !

Hello Raoul, welcome to the Prismic community forum!

Yes, this is possible. You do this by using the FullText search. The syntax is different, because the id_in argument just receives a string or array as a variable.

First, you need to specify the language of the documents you’re going to be querying in.

Then you have three options:

Hello Paulina, thank you for your answer !
I’m looking to search on a specific field with multiple search terms.
The problem with where:{title_fulltext:"apple banana"} is that my title field must have apple AND banana but I need to request the documents where title is apple OR banana.

Thanks !

1 Like

Hello again Raoul!

We answered a similar question about this in this other thread:

Is there a feature request associated with this? We really need the ability to query with a list of values-- there are multiple posts here that include this as an aspect. And/or support for filtering with basic boolean logic.

Hey Jeremy!

You can build this using queries. For example, a query using the where argument and the fullText search for multiple search terms:

It depends on your use case. What is the list of values that you mentioned? is it a Group field, a Slice, or the default tagging system maybe?

Thanks, Paulina.

Like the original poster, I need an OR operation and it appears that the full text solution presented is limited to AND, right? (In which case maybe it shouldn't be tagged as "Solution". :wink: )

My current need is to fetch all documents with a key text field that matches any value in a list. Something like:

allFoos(where:{bar: {_in: ["a", "b", "c"]}})

Previously I've needed the inverse, all documents that do NOT match the items in a list. Something like:

allFoos(where:{bar: {_not_in: ["a", "b", "c"]}})

In this latter case (not in the list), it wasn't too inefficient to just query for all documents and filter in the client. In the present case, querying all and then filtering or executing multiple queries is much more costly.

Hey @Paulina! I just wanted to follow up to see if there is a way to full text search with OR rather than AND that I might be missing. Thanks!

Hello Jeremy, sorry for the delay.

At the moment there is still no possibility of using an OR operator in the Fultext search. The most viable solution remains the one recommended by Levi in the original post: "...run two separate queries and combine the results".

I have removed the Solution tag from the Query documents with multiple custom field values post so that it is not confusing for someone else looking for a similar solution. Thanks for the Feedback

Thanks, Paulina. Is there an open feature request associated with the need for an OR search in some capacity? Either extending the existing full-text search, or better yet, as part of extending the logic permitted in 'where' clauses (w/ support for OR, AND, NOT, and in-list / not-in-list operators)?

I'm finding we are needing this capability quite a lot-- and querying all records then filtering in our client or executing multiple queries (well more than just two, potentially) are very inefficient-- especially as we begin to scale our system.

Thank you!

Thanks for the feedback and for sharing your use case @jeremy2!

I understand why creating these queries would be an advantage when developing projects with GraphQL. At the moment, the Feature Request is already registered on our Product board. If news about this feature is added to graphql arguments, an announcement will be made in the original thread of the Request.

This is being tracked as an open feature request.

If you have another use-case for this feature, you can 'Flag' this topic to reopen. Please use the :heart: button to show your support for the feature and check out our Feature Request Guidelines.