decomp.me
decomp.me copied to clipboard
decompme
Implement database schema for courses
(from my comment in #247)
Course (has a 1-many relationship with CourseStep)
slug - the slug of the course name - the name of the course description - the description of the course
CourseChapter
slug - the slug of the chapter name - the name of the chapter index - the number of the chapter course - the Course
CourseScenario
slug - the slug of the scenario name - the name of the step (could use scratch's name but feels better to store its own name in its object. plus this allows not worrying about the scratch changing and suddenly the name is different, etc) index - which step in the course is this (will be used to gauge completion) courseChapter - the CourseChapter it is part of scratch - a Scratch which is the starting point for the step in terms of code / asm / context content - some html or script or other kind of data which is the "course material" (probably best to start as just text for now)
Okay so my suggestion would be the following: Every course should have chapters and scenarios ( = CourseStep in this case) instead of just scenarios, so I would extend the schemes to: Course, CourseChapter, CourseScenario (instead of CourseStep, I feel like it fits better) and CourseProgress.
CourseProgress - a row here represents the progress a user has made on a CourseStep
user - the User courseStep - the CourseStep scratch - the (latest?) fork of the CourseStep's starting point that represents the user's workspace for this step complete - a bool representing the completion of the course - this can also be a percentage if we want to go that route. this also allows the user to restart the course but maintain their completion progress in it
IMO, we should start things easy so things like forking the scenario for each scenario isn't necessary as well as tracking the completion in percent but rather if it has been matched or not (boolean). We could add forking and storing the precise completion later on.
Course (has a 1-many relationship with CourseStep)
name - the name of the course description - the description of the course project - the Project this is part of - kinda unsure about this because we probably want to be able to have courses for just architectures or compilers in general, and fitting those into the eventual project design seems kinda silly. maybe we should just have it be an id and have projects specify course ids. this will require more thinking but can be ignored for now
Yeah, we should have it an id and have projects reference the course ID's instead, i think it wouldn't make sense otherwise. If we would add training to decomp.me itself and the ability that projects can create their own training, I think that this is would be the perfect solution to this.
I agree with the rest of your ideas.
Okay, so this is my suggestion:
Training (has a 1-many relationship with TrainingChapter)
platform - the id of a platform
TrainingChapter (has a 1-many relationship with TrainingScenario)
name - the name of the chapter description - the description of the chapter
TrainingScenario
name - the name of the scenario slug - the slug of the according scratch for the scenario content - html/markdown which is the "course material"
FinishedTraining - a row here represents a finished training scenario by a user
user - the user slug - the slug of the scratch
If we would implement training in projects later on, we could just reference a list of TrainingScenario then, or even TrainingChapter. Training is only for the global training of decomp.me. We can also use FinishedTraining universally for both global training and project-dependening training as we only have to store the user and the unique scratch slug to track which training scenarios have been finished by an individual user. I want to keep it very simple so keeping track of the exact progress of a training scenario goes beyond the scope of what I'm trying to achieve, as well as forking a scratch for training.
As of right now, I finished the implementation for FinishedTraining on both frontend and backend fyi.
Course
slug, name, description
CourseChapter
slug, name index foreign key to Course
CourseScenario
slug? index foreign key to CourseChapter foreign key to Scratch
There's no need for a CourseProgress-like model - a Scratch with the fork pointing to the same Scratch that a CourseScenario points is all we need.