Open fyliu opened 3 months ago
Definitely not opposed to changing sponsor_partner
to affiliate
. The way I see it, it depends on the likelihood that we'd add another affiliate type. If there's always going to be only the two, we avoid having to use a foreign key to a separate type table by using the boolean.
org
table is not currently associated with the affiliate
table in any way, because we're the only org using the system. Is this something we want to build in now?The xref tables all use the naming convention table_a_table_b_xref
and I'd like to keep it that way. The name project_affiliate_xref
makes it clear that the table contains the relationships between projects and affiliates in a way that affiliation
does not.
Sorry I thought posted this that day but I didn't click submit.
The consistent table naming convention sounds good. What if we kept the table_a_table_b_xref
as the table name so it's consistent within the database, but changed the model name to Affiliation
so that the coding side looks more like English? I believe django models allows specifying a different table name.
Seems like a good idea to set up the association with the org
table so we don't have to do it later.
I know it was decided that it's going to be an either or for the project sponsor or partner. But I wonder about the likelihood that it will become something like the org where they can be both. Maybe we need to create a decision record or at least a statement so we're confident this is going to be stable.
I think enums or choices are just short strings. Or maybe that's one of several way to do it but it's the one I can remember. If it's set to 1 char long, then there's that many possible values we can later use. Django translates from sponsor
and partner
to s
and p
for our case. We set up the mapping ourselves in the code and the db sees the short strings.
You're right. I realized while testing the PR that the affiliate
table needs a uniqueness constraint on the (project_id
, sponsor_partner_id
) pair. I'm making it part of that issue.
From comment above:
sponsor_partner
table to affiliate
because a single word is easier to use than 2
project_affiliate_xref
(Affiliation) table's uniqueness constraint is being done in #65 in PR #270From the meeting:
Affiliation
for ease of coding, but need to keep the database table name for consistency with the existing xref naming convention.
affiliate.is_org_sponsor
into a FK relationship with org
. It looks to be a good idea but can be discussed more and decided later. affiliate
's ability to be both partner
and sponsor
to org
, but is limited to either partner
or sponsor
to project
is a business requirement, so we will implement it this way.I forgot to bring up the enum during the meeting. It's part of #65 so I'll comment there.
Cleaning things up a bit here. I made some of the changes part of #65 since that's being worked on right now. The only change remaining here is what the title says.
I just realized I still haven't confirmed the boolean to enum change but it's already being coded. Will have to do that with @Neecolaa at the next meeting to figure out what's best. We can undo the code change if it's not a good direction.
Here's a comparison of them.
boolean (database boolean)
enum (database varchar)
After a discussion with Bonnie at the People Depot meeting, we've decided to add the boolean is_partner
to project_affiliate_xref
.
A partner is an entity that's doing ongoing work with us on the project. A sponsor is an entity who has provided funds or an in-kind donation.
Unassigning @freaky4wrld since the coding is done. We just need to change the ERD and spreadsheet for the rest of this issue.
Overview
We should rename the
sponsor_partner
table to something likeaffiliate
. And theproject_sponsor_partner_xref
table toaffiliation
or similar. This would simplify and clarify the ideas behind these tables.Also more clear would be converting the
project_sponsor_partner_xref.is_sponsor
field totype
. See discussion below.Action Items
ERD, spreadsheet, code changes for each of these
sponsor_partner
toaffiliate
project_sponsor_partner_xref
toaffiliation
. Made part of #65is_sponsor
field name totype
and make it a choice or enum. Made part of #65Resources/Instructions
Proposed Changes
project_sponsor_partner_xref
table toaffiliation
or a more appropriate descriptive term for the relationship.sponsor_partner
table toaffiliate
.is_sponsor
is a choice like choose between sponsor or partner, and call ittype
What the changes give us
Mostly simpler naming for these concepts.
Clearer code when working with the relationship and model.
Example to create a project-affiliate relation
The current way would look like this
_Originally posted by @fyliu in https://github.com/hackforla/peopledepot/pull/270#discussion_r1529113443_