-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Groups of course units #122
base: master
Are you sure you want to change the base?
Conversation
I think it not a very idea, in terms of scale, to hard coded the groups in the database and a more generic approach should be followed. What is the different between "Competências Transversais" and "Optativas"? The name? The groups feature are useful not just for "Competências Transversais/Optativas", but also "Ramos" which many masters have. Example I know this makes the task so much difficult, but I wanted to you to remember how big the job you are dealing with, and how important it is for the expansion of the project to others courses and faculties. |
My first idea to deal with this issue was to create 2 tables one for groups and another to map groups to course units allowing a many to many relationship which I think would be more generic and versatile. During the meetings I got the idea that the vast majority of groups were either competências transversais (where you can choose one) or optativas (where you can choose a certain number) and therefore I decided to go with the easier approach of just adding a group attribute to the course unit. But given that we want to expand to other courses where there will be many other groups (probably) like the one you refered , I believe an approach closer to my initial idea would be better. |
I like your initial approach. Besides looking an overkill solution for this first phase, it will help scale next |
I don't know if it makes sense to be a many to many relationship between a course unit and a group, but in terms of scalability as you pointed out it may make sense, so it's ok to do that. A group is different from a branch. A group can be inside a branch, so they are not the same thing. Is your idea to include branches in the table that maps course units to groups? By mixing groups and branches up in the same table won't we lose the possibility of having distinct behaviour in the future? (because we may want to display them differently in the frontend) |
You are absolutely right. I didn't see the groups inside the branches, but they exist. So a branch is a whole other story we may be aware of. I still think writing the name of the group directly to the database is not the best approach, and inclined to a many-to-many relationship. I don't know if we will get a surprise of finding another group type later. |
I looked into the different group names that the scrapper ran into and there are more than I had first realized some groups that have "Opção" in the name are actually optativas others have "Opcão" but are closer to transversal it is kinda hard to find a criteria that works for all. When I first implemented that I looked mostly into the scenario of LEIC/MEIC. In addition there are things that look like groups but aren't like "Teses", "Workshops" etc and sometimes there is stuff like "Qualquer UC UPorto". Imo the many-many approach would support all these cases even the "Qualquer UC" ones, the current one doesn't really seem feasible because the distinction between an optativa and a transversal from the name of a group is not clear. An alternative would be just having an attribute isMandatory in course unit and don't make the distinction between Optativa and transversal but that approach would prevent us from distinguishing between groups on the frontend. some cases. |
No course unit groups currently exist in TTS, this pr aims to introduce them
The implementation includes three groups:
Scraping Process
The course page has the course plan url and the course plan page has tables with groups of "optativas" and "transversais" which can be used to classify them.