-
Notifications
You must be signed in to change notification settings - Fork 8
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
Restructure model so Hacker is nested under Account #650
Comments
Infinite +1's to this. A consideration for whoever ends up taking this on would be to think about the lifecycle of a user year to year. A very large portion of hackers will at least apply (if not attend) for 2 or 3 years, thinking about how we can better design the schema to remove friction from later years would be great. For example, I manually duplicated several fields from the McHacks 6 database into the one for McHacks 7. This repopulated a lot fo fields like school, major, GitHub URL, etc... so that applicants simply needed to confirm that nothing changed. Some of these fields we probably don't need to save year to year (i.e. we only want the latest Github URL) whereas fields like their "Why McHacks" essay we might want to maintain the different responses from year to year. Maybe the instance of a the hackathon is nested within the hacker object? Migrating the database to the new structure is likely out of scope of this issue, but in designing how the hacker information is stored, making sure that the new structure is compatible for migration from the old structure would be good. I'd be toying around with the concept of a "hackathon_id" so that one database can span multiple instances of a Hackathon while connecting hacker data between them. Again, beyond the scope of this but having this in mind might help to prevent creating tech-debt for a longer term feature. |
This is going to be a Herculean task, but def worth it. I would recommend creating a new branch to work on this, with many PRs going into that new branch. This will affect almost every part of the API, so this task really should be broken down into sub-tasks on a service-level. This migration will definitely need a design doc too. |
Good points, I'll write up a design spec and break this into smaller issues. With regards to the migration, the current plan is to not migrate any past years' data, instead storing them offline. This will ease migration and leave us with less data to pay for but the downside of this is that hacker accounts will not persist from previous years. Looking forwards to supporting future years, accounts will be subdivided by year in order to add capability to reuse accounts between years like so:
With this previous application answers could be preloaded from the last hackathon the account attended. I really like the idea of Also, all endpoints will stay the same with the exceptions of teams and travel (which need large refactors anyways) and the removal of hackerid, sponsorid, etc. in favor of a universal accountid so updates to dashboard will be minimal. |
This is unfortunate, but I do think it's understandable this years since the database migration will be a lot more complex than last year (though it would still be cool to have it as a stretch goal! if only the usernames/passwords and not the rest of the information). It might not actually be that painful to maintain just the The structure you proposed there looks good, and I do agree that
I'm not convinced this is the best route but it came to mind as a way to keep only the recent profile information and not have an overly complicated API to auto-populate new things on the n>2'th year. |
First part of refactor that will move Hackers, Organizers and Sponsors so they are nested under accounts. This will simplify rolebindings and move us away from the current relational structure. Middleware, validators and other appropriate parts of the source will need to be updated to reflect the new structure.
The text was updated successfully, but these errors were encountered: