Basically I have a list of things with criteria. I’ve also got a big table full of log entries. Each individual log entry might fulfill the criteria of one or more of the items in the first list. So I need to search/sort/filter the whole table of log entries by user, time, and criteria for each of the items in the list.
What I’d like to do is get one boolean value: yes if any one of the items in the list’s criteria isn’t fulfilled by any of the log entries. That way I can raise a flag for the user.
So right now I have it running in a repeating group. The list gets applied to the repeating group and each cell searches the entire log. That way each cell can have a yes/no this item’s criteria is satisfied. But I can’t get that data out of the repeating group.
Is there a way to put all of that into one expression? Something that doesn’t require the explicit iteration?
I think I figured out how to visualize it.
List A & List B. Any number of A can match up with any number of B. Like this; I need to at least know that one (or more) of the items doesn’t match up with any of the items in the other list.
I don’t totally follow your suggestion. I think the core difficulty is that I’m looking for a many-to-many relationship. Any number of one list can match up with any number of the other list. So each item in one list has to be compared to every item of the other list (ignoring filters and such to shorten the lists). Not sure how to do that without looping.
Is there a way to get data out of the cells of a repeating group? I’m not aware of one. If there was then I could use the repeating group as the loop and pull out the result of each cell’s calculation into a list. That would do what I needed.
Assuming your list of criteria is in a table called criteria, and your list of logs are in a table called entry, it’d look like …
search for criterias < search for criterias
search constraints as you have them, with an additional constraint on the first search …
preset is in search for entrys
search constraints as you have them.
For your visualisation example, if A is criteria and B is log entries, assuming the grid shows all matching the date constraints, the expression would show as 7 < 9, which is true, which means there are some criteria unfulfilled.
Basically an Event is a “to do” item. The user enrolls in a particular Protocol which has a list of Events. Each event describes logging an Entry with a particular Preset at a particular time.
The criteria for whether or not an Entry satisfies the criteria of an Event is
user
time
preset
So I search table Entry for any record that matches those three criteria. Count > 0 means that particular Event is satisfied. But then I need to run the search for every other Event, because each Event has its own set of criteria. Thus I end up back at looping.
The other way around would be searching Events for a match to an Entry. The criteria would be
time
preset
So I search table Event for any record that matches those two criteria. Count > 0 means that particular Entry satisfies one or more Events. But then I need to run the search again for every other Entry.
Basically, a search can only have one set of criteria. I need a way to run a search with a list of sets of criteria.
Just making a note that Bubble’s inability to do real-time repeats is adding at least 1-2 days of development time. That’s a relatively significant amount of time. It’s also introducing more potential errors because Bubble also doesn’t do well with branching logic, which I have to use to make up for not being able to loop. This also means I have to add a lot of “empty” records to the database as placeholders so I can search for them later.
I changed the data structure to store all of the information in one table. I’m still dependent on at least one repeat using “schedule an API workflow on a list” so I moved that to the sign-up step. That way any delay caused by long waits between repeats will hopefully happen while the user is distracted and not waiting on them.
So, no looping in real-time means extra database records (+25%), more brittle workflow logic, and longer development time (+1-2 days).
Maybe real-time repeats could be added to the paid plans? @emmanuel
