Hello
I don’t understand how it works, it’s strange
It is quite clear with image of code
Why the relation display “true” , fills the field, when the value is not the same
But If change the relation I have this
I do not understand anything
If you have an idea, thanks for your help
I’m not sure what you are trying to achieve but would it help if you selected “match multiple” in the configuration of your relation?
Your screenshot showing a relation that compares the User-Club to the Club is the correct way to do it. Only one administrator row has a match.
When you flip your relation around and compare Club to User-Club, then every club row happens to find an administrator row, so the relation is populated for every row.
If I recall your scenario, you are trying to mark which user is an administrator, so the administrator row should be looking for a matching relation instead of all records in the club looking for a matching administrator row.
Hello Jeff
So the admin can update the users of his club and not the others, it works well.
But in this case, how can the relation, which is supposed to make a correspondence between two fields and thus give a found value, work if the two fields are different?
This match is “True” in the User-Club-Admin to Club-Admin relationship, I only have one match.
According to my little computer knowledge, the two relationship should give the same results. This is what I do not understand.
It should be noted that this works for my app, but it is surprising and misterious for me.
Thank you for your advice
A relation looks for matching related rows across the entire table.
When you set up a relation FROM User-Club-Admin TO Club-Admin, then you are looking for every related row that has the same value as what is in the current row. So in your example, only the admin will find several matching rows, but the other users will not find a match at all.
When you set up a relation FROM User-Club TO
User-Club-Admin, you are still looking for every related row that has the same value. But in this case every user will fund a matching admin row.
Relations are not like IF statements where you are comparing left and right values and getting true or false. Instead they look for and return ALL rows where a match is found.
An admin will match with multiple users, so an admin to users relation will only show matches on a SINGLE admin row. All users will match with an admin, so a users to admin relation will find a single match on ALL user rows. The direction of the relation is very important depending on the result you want.
Again, with the relation, you are not just comparing the two values on a single row. That’s what the IF column is for. Instead, you are comparing one value in each row to ALL rows in the related table. A matching value in ANY row will be become related to the current row.
See please this picture
Sorry Jeff, I can’t seem to figure out how you describe it, but like said in my previous post, this quirk suits me well, because that’s exactly what I wanted to do.
If you program in Oracle a relation like this, it will give no result, whereas in Glide it gives matches, there must be something else, but what?
It looks like you are relating the User-Club column to the User-Club-Admin column. With your relation set up like that, every single row that contains ‘ASS Golfeurs Le pecq-Responsable-true’ in the User-Club column, will look for that exact same matching value in all rows in the User-Club-Admin column. In this case, only the Admin user has that same matching value. Since it found the admin user as the matching related row, then all users for ‘ASS Golfeurs Chavillois’ will show one matching relation. That row in the relation is the Admin user and only the Admin user.
I guess to me, relations make perfect sense and work very well, but I can understand that they could be confusing at first. Think of it like parents and children instead of admin and users. A parent can have multiple children. A relation from a parent to the children would return multiple children in the parent row. A relation from a child to a parent would show the same matching parent in all children rows. Your current relation is attempting to relate each child (users) to a parent (admin). Because of that, each row shows a matching relation because each club-user (child) is finding a matching club-user-admin (parent).
Hello Jeff
So the behavior of RELATIONS Glide looks like this:
In the relation between ADMIN - USER, Glide searches in the USER column for the occurrence, or all the occurrences, where the value of ADMIN appears there, here ASS Golfeurs Chavillois-Responsable-true, and it indeed finds it there is has a field in USER which has the same value as in the ADMIN field (ASS Golfeurs Chavillois-Responsable-true).
Then Glide looks for this value in the ADMIN column on all occurrences = at that value. And for each row found, it displays the value of the first field of the row, here the name of the user “Pallier” which in my case corresponds to the admin.
This is proven by the change of order of the relation, USER - ADMIN, where I find only one occurrence.
For me, a TRUE relationship (data base) should give a single result, but the GLIDE algorithm does a lot more. See previous pictures.
What is strange to me is the ambiguity of the word Relation (Glide) which is quite different from a database relation eg: ORACLE.
But hey, you have to understand how it works and so you will know how to use it as it should.
Thank you so much Jeff for helping me figure this out.
I’m more familiar with DB2 and SQL Server, but according to the Oracle document below, which aligns with how I understand and use relational databases at my day job and within glide, relations are much more than a one to one check for a match in a single row. They can be a one-to-one, one-to-many, many-to-one, many-to-many. In more cases than not, I expect to have more than one resulting row from a relation. A well designed database does not duplicate any data, other than the unique keys used to create a relational link between a parent record and the children records. That way, common data can be shared across other multiple rows of data, through the relation, without the need to actually duplicate the data.
https://docs.oracle.com/html/E79061_01/Content/Data%20model/Define_a_relationship.htm
I don’t feel that glide is doing anything beyond what any other traditional relational database would do. When you create a relation in glide, your are simply asking, “does the value in this column, in this row, have any matches in the destination column, in ANY of the rows of the destination table…and if so, return ALL of those matching rows”. This check happens for every row in the source table, so in some cases, a relation could return 0, 1, or several related row records depending on how many related matches it finds.
I think the confusing thing here is that you have a self relation back to the same table. That is usually not the typical use case for a relation. I sometimes do self relations because I want to display details about that same row in a tile or card inline list with a single matching row…but that’s an entirely different use case and more for crafting a UI look instead of additional functionality.
When you asked about this several weeks ago, you wanted to mark a user as an admin, but also show a list of all related users to the admin. The proper relation you need is to link the user-club-admin column to the user-club column. This will give you a multiple relation with all of the users in that particular club, but only the admin row will find the multiple matches. For the rest of the users, the user-club-admin value in their row will never find a match in the user-club column, so the relation will always remain empty for non-admin users. Then you can just use the relation as the source of an inline list when the admin is viewing their own details. The admin will see all related users in their club.
Now it also appears that your boolean is checking if the relation is empty or not. This should still work in this case, but you really could shortcut it and just check if user-club-admin equals user-club. It would still only be true for the admin.
You’re right Jeff, Glide works well in relationships; I will treat the two columns USER and ADMIN as one table, whereas Glide treats them as two different tables, hence my confusion.
I hadn’t had the opportunity to self-relate until now, so for me it’s a discovery.
Thank you again Jeff for your contribution and your patience in explaining all this to me.
