8000
Migration to M:N relationship between students and groups · MindLeaps tracker · Discussion #2114 · GitHub
More Web Proxy on the site http://driver.im/
You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a big change so we can mention some concerns about it in this discussion. There are many systems that depend on a student's group, and I'm sure we are going to miss some.
Currently, a student belongs to a certain group. Original design assumed that students will never change groups, but of course, that was wishful thinking. Students do change groups which forced us to implement a concept of enrollments to know when they changed groups.
This change also necessitates that we do not depend on querying the student's current group for any analytic queries, but refer to enrollments instead. However, we still have a group_id field on students. There is no architectural reason for this to exist anymore. Source of truth for groups should be the enrollments table. This would also give us the ability for students to belong to multiple groups.
However, without belonging to a group, students should now belong to an organization as there needs to be an entity that owns a student.
Here are some concerns about this change:
Analytics for the most part depend on views that do query enrollments so they are probably fine, but we need to double check if they would still work without the group relation
Mobile App expects students to belong to a group. Obviously that will need to change but how should we perform that migration? Probably with API versioning but if we change the backend we need to determine which of many groups are we going to include in the old API response
Need to make sure that when we create students we ask for the organization the student will belong to and then optionally a group
Students do not need to belong to any groups anymore. They can belong to an organization and not be enrolled anywhere
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
This is a big change so we can mention some concerns about it in this discussion. There are many systems that depend on a student's group, and I'm sure we are going to miss some.
Currently, a student belongs to a certain group. Original design assumed that students will never change groups, but of course, that was wishful thinking. Students do change groups which forced us to implement a concept of enrollments to know when they changed groups.
This change also necessitates that we do not depend on querying the student's current group for any analytic queries, but refer to enrollments instead. However, we still have a
group_idfield on students. There is no architectural reason for this to exist anymore. Source of truth for groups should be theenrollmentstable. This would also give us the ability for students to belong to multiple groups.However, without belonging to a group, students should now belong to an organization as there needs to be an entity that owns a student.
Here are some concerns about this change:
Beta Was this translation helpful? Give feedback.
All reactions