I have a Choice component showing a self referential Relation. The relation, (Super-Task) is based on Row IDs but I display a (non-unique) Text column, Summary, to make it easier for the user.
I want to filter the Choice so that it does not present the current row as a choice but it appears I can only filter by what I’ve chosen to display, Summary, which is not unique.
I’d like to set aside the challenges of recursive structures in Glide and circular vs self references for the moment as I will probably handle these in Google Sheets. Considering just the filtering, the problems with the example (for me) are:
The Relation (Super-Task) is based on Row ID and I want to filter by Row ID, not by what is displayed. The display of Summary is a UX convenience and not what happens ‘under the hood’.
Summary is not unique so filtering by Summary may exclude rows that are not the current row.
In this case Summary is volatile as it is in a recursive structure and is not a key so it can be edited. If I use Summary as the filter criteria after modifying the Summary value on the same Edit Screen the original Summary text (and Row ID) now appear in the Choice srop-down.
Is there a way to display Summary but filter on Row ID?
Grateful for an answer and apologies, I’m still new to Glide and ran into a recursive structure and circular dependencies on my second attempt - I have read a lot about all that since (thanks to all) so I realise the filtering question is based on a special case and I don’t want to waste your time worrying about anything except the filter question. Thanks for all the great material in the Community.
hmm, I’m a little surprised that does not work. Do you have a self-contained sample that you could share (ie. make copyable), so that I could take a look?
Okay, I’m stumped. I can’t figure this one out.
I even made another App with a similar setup, and I get the exact same behaviour.
I must be missing something. @Jeff_Hager - want to take a look when you have time?
Yeah, I can take a look later, but something really weirds me out about writing to a relation. I can’t wrap my head around how that is supposed to work, or how it would be expected to work. A relation connects to a row, not a column, so how do you know where the value is even supposed to go? I know there is some exceptions with Airtable and Linked Records, but I just don’t see how that would work with any other type of data source.
It was offered in the target drop down and made sense from that perspective. We can make the target Parent, if that helps.
Quickly tried that and I see the same result. The two approaches seem to be functionally equivalent, i.e. They both write the parent ID to the Parent column. Good idea, though, thanks.
haha, yeah that caused a minor explosion in my head as well
Once I looked I could see that it’s a single relation, and it writes to the column at the other end of the relation. So kinda makes sense, but yeah I never knew that was a thing, so learned something new
But, I can’t for the life of me figure out why filtering on row ID won’t work in this scenario. Tempted to say it’s a bug, but I really think that I’m missing something…
Thanks @Darren_Murphy and @Jeff_Hager, that’s about as far as I got. I’ll leave it a bit for other comments and then move to bugs if nothing comes up. Meantime I’d love to hear the Glide perspective on the writing to the relationship because I think it is a feature. Certainly the results are the same. Thanks again for your help.
It works with Glide Tables. Conceptuly it would be easy to implement. It writes to the correct column and it appears as an option in the drop-down list so I happily used and thought no more about it. If it doesn’t work with all data sources it has no business being in the drop-down. . That said, now everyone has made the newbie nervous…
It would be good to hear the official advice on best practice.
I just noticed that not only does it work but it is the default. If you add a choice, by default it selects to write to the first Relation not already in a component. I guess that confirms it is standard practice.
I’ve created a new app to demonstrate the issues and allow me to move in with the main app.
There is a workaround. Filter of self referential structure by Row ID works if you bring in a copy of the Row ID in a Values from Screen Component.
I’ll change the referenced app in the previous messages and raise this is a potential bug if no one has a better idea. Here is an description of the demo app and steps to reproduce. I am still targeting the relation as this is the default and does not effect the behaviour.
Filter by Row ID does not appear to work in a self-referential structure.
Reproduced in a modified version of the Things template app.
Things have Row IDs.
Things can contain three other things but must not contain themselves.
Choice for the 1st thing is filtered by Name.
Choice for the 2nd thing is filtered by a Row ID
Choice for the 3rd thing is filtered by a setting from Column Value Row ID.
This demonstrates two problems with filtering in self-referential structure and demonstrates a workaround for one.
(a) Filtering by Name is unsafe because Name is volatile. Steps to reproduce:
Edit the Thing named ‘Bloko’
Note there are three contained things in Bloko
Activate ‘Relation Filtered by Name’ Choice drop-down and note that ‘Bloko’ is correctly filtered from the Choice.
Click ‘Done’ to return to edit screen.
Edit Bloko name so it is distinct but recognisable, e,g, ‘Bloko Bloko’
Activate ‘Relation Filtered by Name’ Choice drop-down again and note that ‘Bloko Bloko’ is NOT filtered from the Choice.
Choose ‘Bloko Bloko’.
Edit ‘Bloko Bloko’ back to ‘Bloko’.
Note you have now bypassed the filter and created a self reference.
Note also that in the Edit Screen the ‘Relation Filtered by Name’ Choice is now blank even though it is in the data table
(b) Simply Filtering by Row ID does not work at all. Steps to reproduce:
Edit the Thing named ‘Bloko’
Activate ‘Relation Filtered by Row ID’ Choice drop-down and note that ‘Bloko’ is INCORRECTLY NOT filtered from the Choice.
Choose ‘Bloko’.
Note you have now bypassed the filter and created a self reference.
WORKAROUND is to filter by a copy of Row ID. Row ID is brought into the screen as a Value from Screen that sets a column value Row ID Filter and this is used to in ‘Filter by Column Value set Row ID’.
Edit the Thing named ‘Bloko’
Activate ‘Filter by Column Value set Row ID’ Choice drop-down and note that ‘Bloko’ is correctly not filtered from the Choice, so filtering works and …
Editing the Name is now safe because it will not reveal the same records Row ID in the Choice.
This is just me, but when I’m setting the ‘Write To’…I prefer to know exactly where I’m writing that selected choice value TO. A relation doesn’t tell me where that value is being written…which column…which table. Besides, a relation has a source column, so it makes more sense to me to write the value to the regular source column that’s being used to build the relation.
I’m also pretty sure that you miss out on some other component configuration settings when you write to a relation, such as being able to set the source of data for the choice component, being able to set a default value, and possibly some other things. For those reasons I figure that it’s maybe causing issues with the filter.
It makes complete sense to use a relation as a source for the choice component, but it’s not intuitive to me to use a relation as a destination because a relation is a link to rows. Not columns. The option to use a relation is needed for airtable linked records (which are like relations, but different) because of how airtable does things with that type of column. I like knowing how things work, instead of having faith that it just works. I’ve seen too many things in my career where something works 99% of the time, but then there’s that one time it doesn’t work because something was does unconventionally. Writing to a relation may in fact be a supported feature, it just feels wrong to me.
PS. I still haven’t had a chance to take a look at your demo app. Hopefully today or tomorrow…
Thanks @Jeff_Hager for the background. On your advice I’ve changed the app to use the column storing the Row ID for the relationship and the Row ID for the value. Many thanks.
Does that make your filter work, or is there still an issue with that?
It may in fact still be a bug when writing to a relation, but I’d have to spend some time playing around with it.
Don’t get me wrong, the ability to write to a relation does seem to work and does seem like a feature, but I also would like to see an official explanation or documentation on how it works. All I know is that the ability to use a relation was added because of airtable, and maybe it carried through for other data sources.
Darren brought it up in a private expert group and Robert explained a little bit how it works. One advantage I guess is that it shortcuts having to set a source table for the choice component, and based on how the relation is set up, it just knows which column to write the value to. I think I’ll have to play around with it myself to fully wrap my head around it.
The problem is still there either way and I’m happy to leave it as is in the sample which demonstrates two problems and the workaround.
Very glad you shared your experience and also glad that the experts group clarified how it works. That makes sense and as a beginner, I’ll probably stick with the default (new way) just because it assumes the write to target and the value to use without me having to think about it - lazy.
It’s great when you can come back with a new perspective and close the loop.
I’ll let this sit for a day or two and then flag it as a potential bug. Glide may tell me that the workaround is the way you are supposed to do it but none of the documentation explains that. I won’t mark a solution until I get a bit more feedback on a possible bug.
These nested structures crop up all the time for me and I’m really grateful for the time you put in to helping me.
I took a look at your app. Writing to a relation is still weird to me, but that’s neither here nor there. Use what works and makes sense for you. That’s the great thing with Glide…there’s multiple ways to get the same thing done
As for the filter, yes, I agree that it’s definitely not working as I would expect it to. I tried RowID is not Screen->RowID, and I also tried RowID is not Screen->Template-RowID. Neither filtered out the RowID. Only your RowID Filter worked. Not sure what’s going on there.
