Add model changes for real classes #71
base: master
Are you sure you want to change the base?
Add model changes for real classes #71
Conversation
…er into add-model-changes-for-real-classes
This is the 'staging' commit for all the work that needs to be finished before we can implement the CourseShell model. Notes: - Renamed Course model to TransferCourse - Changed access url to `/api/transfer-courses` - New url endpoint will be `/api/courses` for the joined viewset - Added base model for real MTU classes - This WILL break deployments since the sync scripts cannot yet write to the correct model. The scrape script for MTU classes needs to be finished first.
|
||
There's only one cyber sec at MTU | ||
MTM<================>MTM | ||
''' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's some additional notes about this, the main point though is that there will be data loss when we join these two data sets. Namely the strange $COURSE_CODE 1XXX courses that are pulled in from places. Along with "Unassigned transfers"
db_table = 'course_shells' | ||
|
||
|
||
class TransferCourse(models.Model): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
None of these model fields are in any way finalized so if anyone has comments about what they could/should be lmk.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm having some trouble understanding the Shell model. Why is it a many-to-many relation between Shell and MTUCourse?
- Fix up some documentation errors
I hadn't heard that before but I see the sense in it. However looking at the data MTU stores the data with only two decimals anyway so really I don't see any issues coming about from this. I do think that eventually with the cart system a "total fees" would be useful to have. If it does become an issue ever we can switch over. Or I can increase the floating-point limits. |
I don't really think an enum would make sense since it would require a code and database change for a new tag. With this current tag model, it's very arbitrary on purpose so that we can actually do things like labels based on location. In the sync script that feeds from the scraper we just do a update_or_create() model method that creates a new label and applies to the current object. Since that bit of I think farther down the line as well after we collect data from rate my professor we could also add a tag to show that. |
This is the 'staging' commit for all the work that needs to be finished
before we can implement the CourseShell model.
Notes:
/api/transfer-courses
/api/courses
for the joined viewsetthe correct model. The scrape script for MTU classes needs to be
finished first.