You are correct. This was working fine in prod last year, and now it is not. Great. I’m glad we had this discussion and I’m sorry I was unwittingly misleading you.
I’m going to look at potential performant fixes, the only thing I can immediately come up with is a data model change to compress your list into an additional attribute on the table, space separated (via :join with). Then your query constraint can become
new_attribute CONTAINS KEYWORD(S) list-element
This is untested though and is only based on my understanding of contains-keywords behavior, that it will catch a true if at least one keyword is valid.
In the meantime, the :filtered application you suggested is the only remaining go-to, aside from :merge. in a variety of applications. Merge gets very brutal though with large sets.
For posterity, the above mentioned theoretical design DOES NOT work.
EDIT: The only other (kind of wacky) way to keep it on DB is to:
-Assign a SELF_ID attribute to the table, that mimmics the Unique_ID column (needs to be manually set after every row creation everywhere in the app)
-Your DB constraint becomes
SELF_ID NOT IN ( Do A Search For TABLE’s SELF_ID, constraint table_list DOES NOT CONTAIN (search_filter_list))
This does the trick via DeMorgan’s law.
Other than that, rolling this back to :filter is the only other way to achieve the desired behavior.
