How come dynamic constraints aren't a thing?

Questions
1

I know you can restructure/clean data but dynamic constraints would make things a ton easier.

For instance, i have a datatype of film metadata which contains 50+ fields and some of these fields are channels with yes / no values to say which channel the film is currently live on (the datatype matches the source data to reduce the need for complex workflows for data cleaning).

i want to create an RG to show titles that say “no” for specified channels i.e. there’s a dropdown with all the channels (30+ channels), the user selects a channel and the RG filters by the selected channel (which is a field in the datatype) and returns the entries with “yes” in this field.

If i could simply Do a search for > constraint > add custom state instead of selecting a static field, i could simply store the selected field name in a custom state and just have one constraint. Unless i’m completely missing a way to achieve this same effect… (without a ton of conditionals).

2

You mean you have fields like:

Field 1: ‘isLiveOnCNN’
Field 2: ‘isLiveOnBBC’
Field 3: ‘isLiveOnFox’

Instead of a list of networks that the film is live on?

3

You can have the data load in an invisible rg and have one condition on the actual RG to change the data source when the state isn’t empty - the first rg and reference it and :filter by the data type.

You’ll save a lot of WU for searching and filtering will be near instant

4

Correct, here’s an example of how the source data is formatted

Screenshot 2024-11-15 at 9.41.29 AM
Screenshot 2024-11-15 at 9.41.29 AM2536×156 15.1 KB

5

Not following how this solves the issue?

6

Then there’s the issue. Store a list of Networks on the Film and this becomes easy (because this is how you’re supposed to structure the database)

1 Like
7

I assumed that was the likely answer. I was just hoping there was a way to keep it the same as the source data as converting to a list is going to be a large process.

i already use relational data by having genres, actors etc in their own datatypes, these are fairly easy to process as its one field and just split the values and return the corresponding IDs from their datatype. this however is 30+ fields to combine, how would you approach this without create 30+ “create a thing”'s? seems like you’d have to do:

create a thing > networkList add … > only when channel 1 is yes
create a thing > networkList add … > only when channel 2 is yes
create a thing > networkList add … > only when channel 3 is yes

and so on.

i’ll likely create a relational datatype for networks but combining them into a single list is still the hard bit