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 table will be needed for future tickets. This has to be completed on time.
The database table
To track the state of a tournament, we need to keep its record through a Tournament table.
Other table relations will have to be hooked to this table. But the work to create that relationship will be delegated to the tickets that eventually implements those tables
At minimum, we will need the following fields:
id UUID (the reason why we're using a UUID instead of an int is to avoid people being able to just guess a tournament's identifier through URL guessing)
name a required string for the tournament name display
visibility that takes in an enum ["private", "public"]
code a unique string code (minimum of length 6 that's alphanumeric; case insensitive). This will be the string used to access the tournament (if it's private, a user can type in this code to get immediately redirected and get access to the tournament)
status that maps to enums [pending, active, end]. Pending by default, if status is 'end' then we want to prevent the tournament from being edited (marks it immutable)
created_by that maps to the user table
created_at
updated_at
Note
STILL BEING CONSIDERED IS THE FUNCTIONALITY TO DELETE A TOURNAMENT
because we don't need this yet, we won't need to implement it (especially because it's easy to add deleted_at or deleted_by).
When designing a database, we should only (initially) be adding fields that we for sure will use. It's a lot easier to add fields later on than having to change the behavior of an existing table (consider all the existing data you would have to change). Your first attempt at a database schema design should be as skinny as possible!
Methods we'll need somewhere (at minimum, you are allowed to add more methods as fitting as long as you can foresee us using it)
mark_as_completed that sets the completed_at field
some method to check that the tournament hasn't ended, if ended then prevent the record from being changed
start! that sets the status to active and kicks off the tournament (rest of code to come)
Caution
this table will be needed for future tickets. This has to be completed on time.
The database table
To track the state of a tournament, we need to keep its record through a
Tournamenttable.Other table relations will have to be hooked to this table. But the work to create that relationship will be delegated to the tickets that eventually implements those tables
At minimum, we will need the following fields:
idUUID (the reason why we're using a UUID instead of an int is to avoid people being able to just guess a tournament's identifier through URL guessing)namea required string for the tournament name displayvisibilitythat takes in an enum ["private", "public"]codea unique string code (minimum of length 6 that's alphanumeric; case insensitive). This will be the string used to access the tournament (if it's private, a user can type in this code to get immediately redirected and get access to the tournament)statusthat maps to enums [pending, active, end]. Pending by default, if status is 'end' then we want to prevent the tournament from being edited (marks it immutable)created_bythat maps to the user tablecreated_atupdated_atNote
STILL BEING CONSIDERED IS THE FUNCTIONALITY TO DELETE A TOURNAMENT
deleted_atordeleted_by).Methods we'll need somewhere (at minimum, you are allowed to add more methods as fitting as long as you can foresee us using it)
mark_as_completedthat sets the completed_at fieldstart!that sets the status to active and kicks off the tournament (rest of code to come)set_visibilityset_name