I’m still trying to wrap my head around the concept of Lists…
I have a use case where I need to replace individual members of a group (as the group has a fixed number of active users at one time), but I want to retain a historical record of each member of the group (effectively flag them as ‘previous’ or ‘ex-member’).
I thought I could do this with a list in the ‘Group’ data type but I can’t quite get my head around how I set the status of ex-members in a list. Lists don’t support multiple attribute values do they?
In a relational database, I would approach this with a join table that would have fields: Group - Member - Join Date - End Date, but in Bubble, how would I achieve this with a list? Any thoughts on different approaches?
Note: Individual members can be active in multiple groups
I am seeing this need for multiple attribute values on lists popping up frequently, so I’m looking forward to getting clear on Bubble’s method of handling data in these scenarios.
I just had a similar issue come up in one of my projects. I did it like this:
“Group” has members, which is a list of type Member
“Member” has a User field, which is of type user
“Member” also has an Active Status field, which is a boolean (yes/no)
Build the logic such that when Active Status = Yes, then that Member shows up in the display. If it is No, then that member doesn’t show up in the display.
Rather than having a list for active members and a separate list for inactive members, I just create a list for members and filter on it by their active status. Does this make sense? It’s early for me and my brain may not be working yet.
My usual advice is to think about what questions you want to ask … not think about the data structure.
“List out all the ex members of this group” - a list of Users in a list called “Ex Members” on Group.
“List out all the current members of this group” - a list of Users in a list called “Current Members” on Group.
“List out the current members who are also members of other groups” … So take your first list and do an :instersects with the list from another group.
You will notice we don’t need to go outside the thing we are looking at, it is all there for us, and this makes our queries easier … like the intersection one. … we are not off searching for statuses on users…
So that is asking questions of the Group. What about looking at it from the User ?
I would create something called “Membership” which contains Group (object) and a Status (text). And then have a list of memberships on the User.
"What groups is this User a member of " , Current Users’ Membership list : filtered on Status.
For me that is power of embeded lists, I can write really human readable statements. “Current Users’ Membership list Group’s Name” for example. You don’t need to know my data model to see what that is trying to do.
Yes, it makes a little more tricky on data maintenance , as you have to maintain all the links. But my view is you spend much more time displaying data as you do adding it. So I try to make my life easier on the things that take the time.
I definitely think the Members / Membership approach is the way to go (thanks both). It seems to make more sense to me to do it this way (although I am aware of my limitations in understanding too).
Nigel, I do like your advice. Thinking through the questions rather than the structures is a good way to look at it. Coming from a background where it is all about structures first, it is an interesting challenge to change the mindset, but a valuable one nonetheless…
I’ll start working towards this and see what I come up with.
