OR functionality for constraints

Questions
1

For a repeating group the “data source” is the type User which has a Nationality field in it. I want the repeating group to obtain information for all users that have the word “Japanese” or “Korean” under the field Nationality. How could i do that? I have not seen the option of adding an “or”.

2

Hi @mateo.mulder,

You are correct that there is no way to explicitly OR constraints. However, there are at least a couple different ways to go about it:

  • Use the :merged with operator
    Perform the searches separately (two searches in your case - one for each nationality) and then merge the lists into one using the :merged with operator as follows…
    rg-merged-with
    rg-merged-with718×444 15.4 KB

     
     
  • Use the is in constraint
    Create a separate list of items against which to compare. In your case, this would contain just 2 items - “Japanese” and “Korean”. Then simply search for items where the nationality “is in” that list, as follows…
    rg-is-in
    rg-is-in710×986 22.8 KB

     
     
    One of these approaches might yield better performance, depending on the size of the list and structure of the data, but I haven’t conducted any speed tests. Personally, I’d lean toward the “is in” approach since there’s only one search, and the list of items against which to compare is quite small (just two).

-Steve

Premium Bubble Plug-Ins

1 Like
3

:merged with is how you do an OR search, as @sudsy suggests.

As an aside, I’d encourage the OP to think about whether “Nationality” is a string (text) or if Nationality should be a itself be a Thing (a Nationality).

2 Likes
4

Agreed.

BTW @keith, have you conducted any performance tests using large data sets with the 2 different approaches I described? I’m kinda curious as to which might be best, but I suspect the answer could be “it depends”.

-Steve

5

Good question. Checking.

6

@sudsy, I don’t think you can build a database big enough to notice a difference between the :merge case and the “is in” case.

I don’t really see any difference in a quick-ish check. (Source: Database of more than 40,000 of a certain Thing with Name (text) and Value (fields), all universally unique.)

But this is very similar to any Search. I have yet to see a Search that actually doesn’t return nearly instantaneously. Any search criteria you can formulate (on the server side) return instantaneously.

As you know, there is a difference between the results of a Search (which returns a function that allows you to access all of the found items) and downloading all values found by a Search.

It’s this last part that people often do wrong. E.g., Do a Search for (all of Some thing) :filter by advanced. This, of course forces you to not just find all of the Things, but then resolve them to their component values and then process the client side.

Basically, there’s no practical difference between the :merge and “is in” cases here, AFAICT.

7

One edge case in favor of :merge : There is a limit to how many items a Search will return. This is documented as some value, but I can tell you this documented value is incorrect. However, there must be an upper limit.

In the :merge case, where you are doing 2 Searches, the max number of items returned would be 2X the case of the “is in” Search. (For example, the search for “Japanese” users could yield up to “max search” users, and the search for “Korean” users could also yield up to “max search” users. And, thus, when merged on the client side, you could have more [up to 2X more] Users returned than in the case of the “is in”, which could only yield “max users” of a search for Users who are either “Japanese” or “Korean”.)

8

Really good to know. I appreciate you taking the time to do this and share the results.

1 Like