Do the amount of search constraints affect workflow units or speed?

Do the amount of search constraints affect workflow units or speed IF using only one search constraint is enough to obtain the required list?

For example:
Do a search for Messages
Constraint: Profile = Current User’s Profile

VS.
Do a search for Messages
Constraint 1: Profile = Current User’s Profile
Constraint 2: User = Current User

The first example is adequate in getting the required results, although would the 2nd example have any benefits/drawbacks or any affects at all on workflow units and/or speed?

More constraints make the search more effective, but given the two in the example are essentially the same I think this might be minimal?

1 Like

As these constraints are being applied on the bubble server which is going to return data, they don’t have a significant effect on user performance. Still, if you add a filter on it : filter it does add a bit of processing on the user end.

I read the first filter with one constraint goes to the bubble server too. but With my case filter do add extra processing and if you add an : advance inside a filter that will sometimes become a nightmare.

2 Likes

More constraints = faster searches

Avoid :filter in most cases
Avoid advanced filter in pretty much all cases

Privacy rules to reduce total number of records constraints even need to go through to return.

2 Likes

Are privacy rules effectively acting as a ‘pre-filter’ then? So if the privacy rule says ‘current users company is this company’ then the search will first isolate which company the user belongs to and then ignore all companies they do not belong to prior to attempting to fetch results with the filter constraints applied?

2 Likes

@boston85719 That is correct in your example. Although I’d recommend setting a search constraint regardless for code maintainability

1 Like

Yes, but as @PhastCo said below, include it in constraints too. I personally like redundancy in this case.

Here’s a part of a post I posted elsewhere that goes a bit more in depth with example

Ex) if you have 10,000 users with 1M records of let’s say “messages” in your database without any privacy rules when you do a search on the server or client side it’ll search all 1M that fit in your search constraints.

But if you have privacy rules saying “messages” user is current user and that user only has 300 messages then the server won’t need to search 1M records bc the user doesn’t have access so your constraints only need to search and return from those 300.

Data searches work something like this:
1: privacy rules server side (who has access)
2: search constraints
3: filters
4: advanced filters

Meaning the further you can cut down the lists in the lower steps the faster the later steps will run. You can have a data type with multi millions of records and get it to show near instant results if setup properly.

3 Likes

Thanks @chris.williamson1996 and @PhastCo for the details…definitely a large advantage to use of Privacy Rules outside of their main use of keeping data private.

Don’t have a large enough app to test on big volume of data. Let’s take @chris.williamson1996 example with 1M messages ( 300 of them are related to User A).
We just need to find all messages of User A:

Setup #1: We configured Privacy Rules (Current User can only see his own messages) and make Do a search with no constraints.
Setup #2: We don’t use Privacy Rules and in Do a search expression we add a constraint message_author = Current User (Current User = User A).

So will there be a significant difference between these two approaches in terms of speed?

1 Like

I always use the user constraints just to keep things in line if privacy rules are ever broke/adjusted but yes you would see a speed difference especially as you scale further and even more so if this data was split between multiple data types (12 types, 1M records total between all users, 300 for this user). Also typically the more constraints the faster the data will load.

I’ll probably drop a video demo on this sometime this week.

1 Like

Would certainly be an interesting vid seeing the measureable difference between the two examples. Please let me know when you drop the vid, would love to see :ok_hand: