# This is still a work in progress (mistakes are common).
## For objects that have associated events
> Required in **bold**
- duration: number; The number of users that can be admitted in the event associated to the event.
- eventStartDelay: The number of minutes before the the event starts after the startAt field of the event.
- eventDuration: number; The duration in minutes of the event associated to the object.
- groupSize: number; The number of students that are required to be part of a group.
- groupMax: number; The max amount of members a group should have to be created.
- groupMin: number; The minimum amount of members a group should have to be created.
- expectedXp: number; The amount of Xp an object gives.
- baseXp: number; The starting point of the XP. It's used to calculate the xp per child object.
## Some specific attributes for object types:
- Exercise
- **language**: string; The programming language of the exercise, ex: 'go'
- start: type; Description
- delay: number; The amount of minutes that has to pass after the previous object before the current one is unlocked.
- special: boolean; True for a hackaton.
- startDay: number; The day relative to the beginning of the event associated to the parent event.
- scopeStart
- scopeEnd
- scopeExtraDuration
- auditsRequired: number; The number of approved audits that need to be done to consider an exercise as approved
- exerciseType: string
- `required`
- `enrichment`
- `bonus`
- `asynchronous`
- `synchronous`
- inScope, This attribute is used to determine if the exercise gives XP or not. If an exercise is not in scope then it doesn't give XP.
- status: It can have the values `blocked`, `available`, `succeeded` or `failed`.
- hasStarted
- rootName
- repositoryPath
- difficulty: A number that represents how hard it should be to complete an exercise (as much as that can be quantified).
- difficultyMod: A multipliyer of the difficulty
- Exam exercises:
On top of the exercise of the attributes of a normal exercise exam exercises need the following attributes.
- **group**: number; Identifies the position that an exercise can take in an exam.
e exam takes exercises randomly for each group. For instance: the first exercise of the exam will be an exercise with `group` = 1, the second one will be an exercise with `group` = 2, and so on.
Some exercises require reviews from other students or any other member of the school. The reviewer checks that some conditions are met by the code of the student being reviewed. This process is called an `audit` and it's kept in this table.
Columns:
- id
- groupId, the group that the audit refers to
- auditorId, the user who's making the audit
- attrs, what are used for. What are the possible ones? TODO: look through the code and take them from functions.js
- grade, either 1 or 0
- createdAt, the timestamp of the time and date of creation
- updatedAt, the timestamp of the last update
- code, the code that should be used by the auditor to start the audit
- resultId, the result of the audit
- version, a sha of the commit that the audit refers to
- endAt, the last date that the id refers to
- private, used to access the code by the auditor (needs to be refactored because the requirements changes)
- id.
- groupId: The group that the audit refers to.
- auditorId: The user who's making the audit.
- attrs: The attributes of the audits keep the feedback of the auditor for each question failed.
- grade: 0 for failed and 1 for passed.
- createdAt: The timestamp of the time and date of creation.
- updatedAt: The timestamp of the last update.
- code: The code that must be used by the auditor to start the audit.
- resultId: The result of the audit.
- version: A sha of the commit that the audit refers to.
- endAt: The last date that the id refers to.
- private: Used to access the code by the auditor.
### discordToken
Columns:
- id
- accessToken
@ -25,19 +29,27 @@ Columns:
- expiresAt
### event
An event anchors an objects into time.
> Note: Some `object attributes` are related to time, but they express time only in relative terms to the beginning of the event.
> Also, live edits (i.e., editing an event while is ongoing) it's not supported. The changes will only take effect after reloading the page.
Columns:
- id
- createdAt, the timestamp of the creation of the event
- endAt, the timestamp with the time the event finishes at
- registrationId, the registration to the event
- objectId, the object that is used to generate the event
- parentId, the parent id of the event is based on
- status, confirmation that the event finished correctly (NULL or done for now)
- path, the path of the event (the relative url of the event)
- campus, the campus the event is inserted in
- code, only used to unlock the exams
- createdAt: The timestamp of the creation of the event.
- endAt: The timestamp with the time the event finishes at.
- registrationId: The registration to the event.
- objectId: The object that is used to generate the event.
- parentId: The parent id of the event is based on.
- status: Confirmation that the event finished correctly (NULL or done for now).
- path: The path of the event (the relative url of the event).
- campus: The campus that contains the event.
- code: Only used to unlock the exams.
### event_user
This table links users and events. Many users can be in many events.
Columns:
- id
- createdAt
@ -46,18 +58,22 @@ Columns:
- groupId (not used anymore, TODO: remove at some point)
### group
Some projects are required to be made by groups. Those groups are kept in this table.
Columns:
- id
- objectId, The object that is being done by the group (Usually projects or raids)
- eventId , The groups only exist in relation to an event
- captainId, The captain of the group
- createdAt
- updatedAt
- status, See group_status for possible values
- path
- campus (Auto generated for by the path)
- objectId: The object that is being "done" by the group. Usually projects or raids.
- eventId : The groups only exist in relation to an event
- captainId: The captain of the group.
- createdAt.
- updatedAt.
- status: See group_status for possible values.
- path.
- campus (Auto generated for by the path).
### group_status
Columns:
- status
Possible values (for now)
@ -67,66 +83,68 @@ Possible values (for now)
- `finished`
### group_user
This table links users to groups. A user can be in many groups and a group contains many users.
Columns:
- id
- userId
- groupId
- confirmed, Transitory state while it's not confirmed means
- confirmed: Boolean. False by default. True after the user represented by the user id confirms the group.
- createdAt
- updatedAt
### match
It is used for the `bet` system in the bonus exercises. Specifically to keep a record of the matches between students who will review and make a bet about each others code.
Columns:
- id
- createdAt
- updatedAt
- objectId, The object that requires the match
- userId, The user that is matched
- matchId, The matched that is made to another user
- confirmed (The same as in group_user it's way to keep track of invitations that had not been confirmed)
- bet (For the optional exercises that require a bet. A bet can be true if the exercises is expected to pass)
- result, says if the exercise was validated as succeeded by the tester (TODO: reward xp for getting a bet right)
- objectId: The object that requires the match.
- userId: The user that is matched.
- matchId: The matched that is made to another user.
- confirmed (The same as in group_user it's way to keep track of invitations that had not been confirmed).
- bet (For the optional exercises that require a bet. A bet can be true if the exercises is expected to pass).
- result: Says if the exercise was validated as succeeded by the tester (TODO: reward xp for getting a bet right).
- path
- campus
- eventId, the event the object in inserted in. (Piscine, Raid, etc)
- eventId: The event the object in inserted in. (Piscine, Raid, etc).
### object
Anything that defines the structure of the curriculum? (Onboarding, campus, piscine, raids, etc)
Objects are generic representations of elements in the structure of the curriculum (Onboarding, campus, piscine, raids, etc). They are arranged in a hierachical structure to allow unlimited nesting (see [object_child](#object_child)). They also keep the timeline of the events relaying in durations (ex. `duration`, `eventDuration`, etc) specified by attributes (`attr`).
Columns:
- id
- name
- type, See object type for the possible values
- status (Not used: always online TODO: remove at some point)
- attrs, Same as attrs in the object look for them in `functions.js`
- childrenAttrs Attributes that are applied to all the children objects
- type: See [object_type](#object_type) for the possible types.
- status: (Currently not in used, but it should always be `online` to avoid errors TODO: remove at some point).
- attrs: See [object attributes](#object-attributes).
- childrenAttrs: Attributes that are applied to all the children objects.
- createdAt
- updatedAt
- externalRelationUrl (Not used?)
- authorId (Not used?)
- campus, The campus the object is related to
- referenceId, A reference to the base object
- referencedAt, The timestamp of the creation of the copy object
- externalRelationUrl (Maybe not needed).
- authorId (Maybe not needed).
- campus: The campus the object is related to.
- referenceId: A reference to the base object.
- referencedAt: The timestamp of the creation of the copy object.
#### Attributes (attrs)
##### Objects
- inScope: This attribute is used to determine if the exercise gives XP or not. If an exercise is not in scope then it doesn't give XP.
### object_child
- status: It can have the values `blocked`, `available`, `succeeded` or `failed`
TODO: Finish documenting the json attributes that can be used
Augusto
