changed incorrect ManyToMany fields #245
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
purple-void
requested review from
seporterfield and
Monstarrrr
and removed request for
seporterfield
|
this is NOT ready yet |
Oh sorry lol, can you set it as draft? I don't see it as draft on phone |
|
now this PR is ready for review |
There was a problem hiding this comment.
I was worried about the migration files at first since we just pushed changes to main from another branch with the same numbers on their migration files.
But that's no problem:
Don’t worry - the numbers are just there for developers’ reference, Django just cares that each migration has a different name. Migrations specify which other migrations they depend on - including earlier migrations in the same app - in the file, so it’s possible to detect when there’s two new migrations for the same app that aren’t ordered.
When this happens, Django will prompt you and give you some options. If it thinks it’s safe enough, it will offer to automatically linearize the two migrations for you. If not, you’ll have to go in and modify the migrations yourself
I changed incorrect ManyToMany fields to ForeignKey's (Django's way of ManyToOne).
This includes:
-posts, saved_posts, private_posts, upvotes, and downvotes in UserProfile
-upvotes and downvotes in Posts
Example:
Before, posts were labeled as ManyToMany, meaning that a UserProfile can have many posts (makes sense), but a post can have many UserProfiles (doesn't make sense).
This coincidentally helps with reducing the amount of tables we will use, although this doesn't solve the #229.
EDIT: we renamed that branch to be accurate, so this is a new pull request.