In filtering a list there’s a new option to do advanced constraints like this:
Is there anyway to do something similar to this in a (Do a search for) ?
In filtering a list there’s a new option to do advanced constraints like this:
Is there anyway to do something similar to this in a (Do a search for) ?
Hi there, @ahmadnaser16an… advanced filters aren’t new, and no, you can’t do the same things in search constraints that you can do in advanced filters. Is there something specific you are trying to accomplish or was this just a general question?
Best…
Mike
Here I’m trying to only look for QIds that aren’t in the questions reviews QIds. However, to further optimize it, I would like if in the (Search for Question Reviews) I could only look for Questions Reviews which have a specific question’s lecture.
to further clarify,
Data types involved are:
The only way I can narrow the Question Reviews List is with another search constrain inside that constraint which beats the optimization purpose I’m trying to achieve.
This examples exists with a couple of other data types too.
If the constraints on your Search For Question Reviews aren’t referencing some field on the Question you’re searching for (or in some other way have different constraints for each question), then there is no problem in doing a search within a search… at least in performance terms (if it’s the same search, it will only be done once).
But if the search is different for each Question, then you should definitely try to avoid a nested search here.
But, in either case, it can be good to avoid using searches within searches (even if they aren’t actually causing multiple searches to take place), by doing the search for Question Reviews just once, outside of the QLD isn’t in constraint.
i.e. load the relevant question reviews first into a Custom State List, RG List, or RE Properties List.
Then in your search for questions, just refer to that list in the Qld isn’t in constraint (if you need to filter the list per question, then that’s fine)
That way, you only load the list of question reviews once which, in almost every case I’ve ever testes, will offer significant performance and WU gains over doing a nested search (although, in many cases, nested searches aren’t nearly as bad as many people might think).
But, like everything, the specifics of your use case and data will determine what’s best here… so test, test, test…
If you’re really trying to save on performance, you could find a way to generate only a list of the QLD numbers (rather than the Question Reviews themselves), and use that list in the QLD isn’t in constraint…
You could use a backend workflow with the API connector (and just return a list of numbers, or JSON), or probably even using Search For Question Responses: Grouped by QLD number would do the trick, and minimize the amount of data being returned to the page for the subsequent search of Questions. (in fact, that’s almost certainly the simplest and most performant way to do this).
Thanks a lot.
I like the idea of loading the list into a state or some element before needing to use it.
However, in this case I’m already in the backend workflows so is their a replacement for Custom states & elements in backend?
The intent of the search here is that I want to only look for Questions which aren’t reviewed yet thus there’s no Question Review generated that’s linked to these questions.
However, in this case I’m already in the backend workflows so is their a replacement for Custom states & elements in backend?
There is, with plugins such as List Popper… (although I don’t think you can use Groupings with those).
Another alternative here (probably an even simpler and more performant one), is just to have a yes/no field on the Question to mark whether or not it has been reviewed.
Change that field value to yes the first time the question is reviewed.
Then just search for Questions who’s Reviewed field is No.
This does sound simpler than anything else yes…
Thanks a lot for all the help <3 .
Instead of search inside a search for “is in”, you can try intersect. I had the same problem.