Create table project program area xref 45

[del9ra]

Fixes #45

What changes did you make?

• Created project to program area many-to-many relationship by updating project model
• Tested models relationship and API endpoints
• Updated serializers in project and program area serializers

Why did you make the changes (we will use this info to test)?

• To avoid creating the ProjectProgramAreaXref table because we didn't need any extra fields for the relationship between Project and ProgramArea
• Using a direct ManyToManyField without the extra table makes the code simpler and more efficient

[dmartin4820]

No issues from my review. Good catch on not including the "through" field when there aren't extra fields required on the "join table" between project and program area. I'm going to update PR #385 to reflect that modification.

[dmartin4820]

Based on Fang's comments here, I'm going to request changes for this. It looks like the test I created will not correctly test the relationship. Will check that the test fails without the changes next time.

The code that should be updated based on the above comment is here

[del9ra]

1.Progress: I implemented changes similar to those in Denzal’s PR regarding the ManyToMany relationship. Fang left a comment saying the API test issue needs to be discussed today.
2. Blockers: How to test the APIs correctly.
3. Availability: Monday-Thursday, 1 PM-5 PM.
4. ETA: Expected completion date is October 17th.
5. Pictures (if necessary): No pictures.

[fyliu]

@del9ra is working on updating the commits to the latest upstream/main.

The most prominent problem I'm seeing is the through or xref model fields that are foreign keys should be named something like "project" rather than "project_id".

I think we're missing documentation on this and other "how to translate database table/design into Django model" information. I think we'll have to decide on where to put this and add to it when we realize what's missing. Maybe something like docs/contributing/howto/translate-db-table-into-django.md

[del9ra]

@del9ra is working on updating the commits to the latest upstream/main.

The most prominent problem I'm seeing is the through or xref model fields that are foreign keys should be named something like "project" rather than "project_id".

I think we're missing documentation on this and other "how to translate database table/design into Django model" information. I think we'll have to decide on where to put this and add to it when we realize what's missing. Maybe something like docs/contributing/howto/translate-db-table-into-django.md

I’ll make this adjustment. However, the fields are named project_id and program_area_id in the Lucidchart diagram and the Google Sheet, so I was following the existing documentation.

[fyliu]

@del9ra Sorry about the differences. It's a difference in conventions between the database and Django.

It's customary to append the "_id" to column names to remind the reader it's a foreign key. It helps when typing out SQL queries to compare things like "publisher.id = publisher_id" when joining "book" and "publisher" tables.

In Django, the convention is to drop the "_id" portion when implementing a foreign key column. But even though the Book.publisher ForeignKey field doesn't end with "_id", the underlying database column it writes to will still be "publisher_id". I used an older Django version in the past where it would name the db column "publisher_id_id" if I kept the "_id" in the field name, but Django 4 will name it correctly with either way.

But removing the "_id" in Django also makes the code more readable.
For example

def test_project_program_area_relationship(project):
    ...
    workforce_development_program_area_xref = ProjectProgramAreaXref.objects.get(
        project_id=project, program_area_id=workforce_development_program_area
    )
    ...

project_id is a field but project is an object and it feels a little off when you read it.

So even though Django is smart enough to detect the extra "_id" now, other parts of the system still prefers removing it.

[fyliu]

@del9ra this PR is not reviewable right now because the files changed tab shows a lot of extra changes that are not part of it. It's hard to see what the actual changes are.

I can try to clean them up or you can do it if you prefer.

[fyliu]

@del9ra sorry I didn't realize you made a new PR. I'll look at that instead. You should close this PR so it's clear which one you want reviewed. Thanks!

[del9ra]

Closing this PR because I couldn’t resolve the issue on this branch. I created a new branch and a new PR, where I was able to resolve the merge conflicts. #431