So I’ve been watching the tutorial videos and I’m trying to setup relations but they just don’t seem to be working correctly and I’m not sure why. Two tables - cats and medical. Each cat (parent) may have multiple medical records (child). I set up the RowID as advised. No worries. But now there are things that I don’t understany why they are.
Here is a screenshot of what I’ve set up based on the tutorial:
I tried changing the Name for Charlie to Charlieeee because I figured what if a cat changed a name (not likely but figured good idea to see). I can see where the Medical table field that has the relationship back to Cats (rel_Cats) updated the name, but I don’t understand why, in the Cats table, the relationship back to Medical (rel_Medical) still says Charlie.
I get why, in the Cats table, Daisy and Pumpkin has nothing listed in the rel_Medical column as they haven’t had any medical appointments. All good.
I get why, in the Cats table, everyone else except Jellybean has one listing - because they have only had one medical appointment
I don’t get why, in the Cats table, Jellybean is showing both April Flower and some other blurb. Yes, she has had two appointments - got that right - but where is this incorrect data coming from? I expected two Jellybean tags like the others.
Hoping someone can shed some light on this for me about where I’m going so wrong.
Ignore the values that you see in the relation column. All they are indicating is that a match was made. The number of “bubbles” will correspond to the number of matches found.
The question is - now that you have your relations in place, what do you want to do with them?
For example:
If you want the name of each cat in your Medical table, add a Lookup column, target it at you rel_cats relation, and select Name
If you want to show a list of Medical records on your Cat details screen, add a Collection component and set the source to be your re_Medical relation column.
Thanks Darren. I was expecting the bubbles to make sense… I’ve deleted and redone so many times but getting same result.
Yes, the goal is to list under each cat details their medical history which can then be added to or edited. Now I know I can ignore the bubbles I will try and have a go doing this. Thanks
So what about the name change issue? I’m getting medical details for Charlie and Chralieeee now.
Also, is there a way to see all the screens that have been created including the default screens the Glide automatically create? I swear I’ve created these add and edit screens multiple times but they always seem to disappear and I recreate them again. Feel like I’m going around in circles.
How are your relations configured? Can you show me?
It’s generally good practise to create relations using values that you can trust will not change. A name, for example, is not a good choice. A RowID is the best choice, because it is guaranteed to never change.
I did the RowID as per the tutorial and I thought I did everything the tutorial says but I’m still not sure why this is happening. But here are the relations in the two tables as requested (hope this is what you mean) in the hopes you might be able to see the issue.
I’m going to load one of the example database (inventory) to see how the professionals do it in the hopes I can learn from it. EDIT: I downloaded the example but decided not to use it as a learning base because it does relations to names - which could change - not to RowIDs, as they show in the tutorials.
I’m going to try and load some “real” data in there as maybe I’m confusing myself with all the rubbish data.
Interestingly, I also downloaded the sample Inventory template from Glide (got the email this morning) to deconstruct to see how a real app looks compared to mine and they don’t use relations to RowID there, either, but to name fields. I will have to play with it and see what happens when a name is changed, as in if the relation breaks (given the other tutorial for relations strongly says DON’T link to names but rather RowID).
I have to say, I am impressed with Glide despite running into road blocks due to being a complete newbie and ending up going in circles a bit (well, I certainly feel I am), but it is pretty amazing what it allows someone with zero experience to knock up. I really think this will work for the NFP rescue charity once I learn a bit more and can show them a stable system that can do basic checking (like unique fields and not break when names change) And despite getting a bit frustrated at times, I am actually enjoying it. And the help in this community is AMAZING!
You’ll find that it’s mostly us “purists” that advise using RowIDs for relations. The important thing to understand is that you should avoid using things where the values might change, because when they do your relations will break. That’s why we generally recommend RowIDs, because they will never change. Email addresses are also good for relations, because they rarely change. But if they do change, and you’re using them in multiple tables… well then you have a bit of a maintenance headache.
Another example of where it might be okay to use names is where you have a list of category names. If you’re pretty confident that the category names will never change, then it’s fine to use those in relations.
As with most rules of thumb, there are always exceptions. Once you have a good understanding of how things work and the implications of various options, you’ll find that you instinctively know the best approach to take.
Yes, Glide is indeed a joy to work with, and the community that’s grown around it is first class
And despite getting a bit frustrated at times, I am actually enjoying it. And the help in this community is AMAZING!