|
| 1 | +# Adding Data Persistence Sprint Challenge |
| 2 | + |
| 3 | +**Read these instructions carefully. Understand exactly what is expected _before_ starting this Sprint Challenge.** |
| 4 | + |
| 5 | +This challenge allows you to practice the concepts and techniques learned over the past sprint and apply them in a concrete project. This sprint explored **Data Persistence**. During this sprint, you studied **RDBMS, including SQL, multi-table queries, and data modeling**. In your challenge this week, you will demonstrate your mastery of these skills by creating **a database based on given specifications**. |
| 6 | + |
| 7 | +This is an individual assessment. All work must be your own. All projects will be submitted to Codegrade for automated review. You will also be given feedback by code reviewers a few days after the challenge submission. For more information on the review process [click here.](https://www.notion.so/bloomtech/How-to-View-Feedback-in-CodeGrade-c5147cee220c4044a25de28bcb6bb54a) |
| 8 | + |
| 9 | +You are not allowed to collaborate during the sprint challenge. |
| 10 | + |
| 11 | +## Project Set Up |
| 12 | + |
| 13 | +- [ ] Run `npm install` to install your dependencies. |
| 14 | +- [ ] Run tests locally executing `npm test`. |
| 15 | + |
| 16 | +## Project Instructions |
| 17 | + |
| 18 | +### Introduction |
| 19 | + |
| 20 | +In this project you will be given a set of requirements and must design a database to satisfy them. As a part of this process you'll also build an API with endpoints to access the data. |
| 21 | + |
| 22 | +### Files to Complete |
| 23 | + |
| 24 | +1. `package.json` |
| 25 | +2. `index.js` |
| 26 | +3. `api/server.js` |
| 27 | +4. `model.js` inside `api/project`, `api/resource` and `api/task` |
| 28 | +5. `router.js` inside `api/project`, `api/resource` and `api/task` |
| 29 | +6. migration file(s) |
| 30 | +7. seed file(s) **optional** |
| 31 | + |
| 32 | +### Required Dependencies |
| 33 | + |
| 34 | +The project needs some additional NPM dependencies in order to work. |
| 35 | + |
| 36 | +### Required Scripts |
| 37 | + |
| 38 | +Add `"start"`. `"server"`, `"migrate"` and `"rollback"` scripts to the `package.json` file. The tests depend on these scripts being correct! |
| 39 | + |
| 40 | +### Required Tables |
| 41 | + |
| 42 | +Build the migration(s) in Knex inside the `data/migrations` folder using appropriate data types and constraints. **You must use the table names and the column names described below.** To give a primary key a name different than `id`, do `table.increments("project_id")` instead of `table.increments()`. |
| 43 | + |
| 44 | +- [ ] A **project** is what needs to be done and is stored in a `projects` table with the following columns: |
| 45 | + |
| 46 | + - [ ] `project_id` - primary key |
| 47 | + - [ ] `project_name` - required |
| 48 | + - [ ] `project_description` - optional |
| 49 | + - [ ] `project_completed` - the database defaults it to `false` (integer 0) if not provided |
| 50 | + |
| 51 | +- [ ] A **resource** is anything needed to complete a project and is stored in a `resources` table with the following columns: |
| 52 | + |
| 53 | + - [ ] `resource_id` - primary key |
| 54 | + - [ ] `resource_name` - required and unique |
| 55 | + - [ ] `resource_description` - optional |
| 56 | + |
| 57 | +- [ ] A **task** is one of the steps needed to complete a project and is stored in a `tasks` table with the following columns: |
| 58 | + |
| 59 | + - [ ] `task_id` - primary key |
| 60 | + - [ ] `task_description` - required |
| 61 | + - [ ] `task_notes` - optional |
| 62 | + - [ ] `task_completed` - the database defaults it to `false` (integer 0) if not provided |
| 63 | + - [ ] `project_id` - required and points to an actual `project_id` in the `projects` table |
| 64 | + |
| 65 | +- [ ] A **resource assignment** connects a resource and a project, and is stored in a `project_resources` table. You decide what columns to use. |
| 66 | + |
| 67 | +### Required Endpoints |
| 68 | + |
| 69 | +Build an API inside the `api` folder with endpoints for: |
| 70 | + |
| 71 | +- [ ] `[POST] /api/resources` |
| 72 | + - Example of response body: `{"resource_id":1,"resource_name":"foo","resource_description":null}` |
| 73 | + |
| 74 | +- [ ] `[GET] /api/resources` |
| 75 | + - Example of response body: `[{"resource_id":1,"resource_name":"foo","resource_description":null}]` |
| 76 | + |
| 77 | +- [ ] `[POST] /api/projects` |
| 78 | + - Even though `project_completed` is stored as an integer, the API uses booleans when interacting with the client |
| 79 | + - Example of response body: `{"project_id":1,"project_name":"bar","project_description":null,"project_completed":false}` |
| 80 | + |
| 81 | +- [ ] `[GET] /api/projects` |
| 82 | + - Even though `project_completed` is stored as an integer, the API uses booleans when interacting with the client |
| 83 | + - Example of response body: `[{"project_id":1,"project_name":"bar","project_description":null,"project_completed":false}]` |
| 84 | + |
| 85 | +- [ ] `[POST] /api/tasks` |
| 86 | + - Even though `task_completed` is stored as an integer, the API uses booleans when interacting with the client |
| 87 | + - Example of response body: `{"task_id":1,"task_description":"baz","task_notes":null,"task_completed":false,"project_id:1}` |
| 88 | + |
| 89 | +- [ ] `[GET] /api/tasks` |
| 90 | + - Even though `task_completed` is stored as an integer, the API uses booleans when interacting with the client |
| 91 | + - Each task must include `project_name` and `project_description` |
| 92 | + - Example of response body: `[{"task_id":1,"task_description":"baz","task_notes":null,"task_completed":false,"project_name:"bar","project_description":null}]` |
| 93 | + |
| 94 | +**Important Notes (READ!)** |
| 95 | + |
| 96 | +- Run tests locally by executing `npm run test`. Tests will be very broken until you flesh out the project sufficiently. |
| 97 | +- You are welcome to create additional files for middlewares etc, but **do not move or rename existing files** or folders. |
| 98 | +- Do not make changes to your `package.json` except to add **additional** dependencies and scripts. Do not update existing packages. |
| 99 | +- Delete `test.db3` and `database.db3` and re-run migrations and tests, if you suspect half-finished code left your databases in a broken state. |
| 100 | +- In your solution, it is essential that you follow best practices and produce clean and professional results. |
| 101 | + |
| 102 | +## Submission format |
| 103 | + |
| 104 | +- [ ] Submit via Codegrade by pushing commits to your `main` branch on Github. |
| 105 | +- [ ] Check Codegrade before the deadline to compare its results against your local tests. |
| 106 | +- [ ] Check Codegrade on the days following the Sprint Challenge for reviewer feedback. |
| 107 | +- [ ] New commits will be evaluated by Codegrade if pushed _before_ the sprint challenge deadline. |
| 108 | + |
| 109 | +## Interview Questions |
| 110 | + |
| 111 | +Be prepared to demonstrate your understanding of this week's concepts by answering questions on the following topics. You might prepare by writing down your own answers before hand. |
| 112 | + |
| 113 | +1. Explain the difference between Relational Databases and SQL. |
| 114 | +2. Why do tables need a Primary Key? |
| 115 | +3. What is the name given to a table column that references the Primary Key on another table? |
| 116 | +4. What do we need in order to have a _many to many_ relationship between two tables? |
0 commit comments