Hi Shaun,
I’m don’t think it will cause app performance issues for me, but rather developer speed/readability/surprise issues.
I’m sure there is a good reason it is designed to match on subsets.
In my particular case I am using simple objects to store attributes that handle role based access control (RBAC) functionality.
For example, I have two columns: role and attributes. Role is plain text, and attributes is a simple object.
My users have roles and attributes that are constantly changing, and so I have scripts that pull from our organization’s database and updates the Users and RBAC tables accordingly (i.e., updating/adding/removing roles and attributes).
For example, I often have to ask whether some user’s roles and attributes are different when comparing our organization’s database to the Anvil data tables. I would like to do the following, but I cannot:
# from internal database
actual_user_role='vice_principal'
actual_user_attributes=`{'school': ['school_1', 'school_2']}`
if not app_tables.RBAC_table.get(role=actual_user_role, attributes=actual_user_attributes):
# add a new row to the RBAC table
As you describe, get() will likely not work since my search will be a subset of many rows (so I’d switch to search()), and even if I get a single row back, there is no guarantee that row['attributes'] will match actual_user_attributes.
This means that I cannot use an if statement. I have to pull back whatever matches based on subsets, as you describe, cast values into lists, and then compare those lists for equality. Now that I think about it though, I don’t think this is even feasible since supersets will crash as you indicate above.
I think I have to take a different approach that maybe adds roles and attributes to the RBAC table regardless of what else is in there, and then find a way of removing stale rows from that table after the fact.
What I would love, is a way to use the query operator to say something like:
app_tables.RBAC_table.get(attributes=q.equals({'school': ['school_1', 'school_2']}`)
Either that or make it so that app_tables.my_table.get(attributes=my_dict) implies equivalence, since there is an equals sign, and have q.subset as part of the query operator options.
Perhaps all of this is very specific to my current situation and wouldn’t apply to most users. Anyway, thanks for explaining how things work. I’m sure I can find ways to handle my use case now that things are clear.