Andernial / processo-seletivo-backend-2024

Repositório criado para participar do processo seletivo do instituto TaqTile
0 stars 1 forks source link

[Track 9/9] Relations #26

Open taki-tiler-server[bot] opened 3 hours ago

taki-tiler-server[bot] commented 3 hours ago

Step 1/3 - Feature request!

Estimated time: 15 min

So, let's assume we received a feture request: now our users should be able to have one or more addresses registered on their accounts. The information needed for this new feature is:

One simple solution could be just add these columns on User database table, right? Well... it should be an ok solution if each user should have only one address associated. Since we have the possibility of more addresses, we couldn't know how many columns to add, and so we need to explore another solution for this.

Before continuing, try giving some toughts yourself about how to achieve this 🤔🤔🤔 If you reach a solution, do some research on the internet to compare or explore more possibilities. Then, go to next track.

Andernial commented 3 hours ago

Finish

taki-tiler-server[bot] commented 3 hours ago

Step 2/3 - Relations on Databases

Estimated time: 1 hour

If you thought or researched about relations: yes, that's the way we do it! 😝

You should have realized by now that Postgres is a relational SQL database, but until now we haven't explored the "relational" part of it. So, let's learn and practice this core concept. When we have more than one table, there's a good chance they are somehow related. Let's take our case as an example: our users should now have the possibility to have addresses associated to them. We can achieve this by creating a new table, let's say: "address", and somehow they should be related, because we have to know what address corresponds to its user.

We have 3 simple types of relation: one-to-one, one-to-many and many-to-many. Check this video for more details about each of these types.

As you should have guessed, the relation we will implement here is one-to-many: a user can have more than one address, while an address is associated with only one user. After the video, think about what will be the columns of the "user" and "address" tables.

Check out the spoilers below ```txt +-------------+--------------+ | user | +-------------+--------------+ | id | PRIMARY KEY | | name | | | email | | | birthDate | | | password | | +-------------+--------------+ +--------------+--------------+ | address | +--------------+--------------+ | id | PRIMARY KEY | | cep | | | street | | | streetNumber | | | complement | | | neighborhood | | | city | | | state | | | userId | FOREIGN KEY | ----> this is how we know which user this address belongs to. +--------------+--------------+ The address table has a "foreign key", which is the "primary key" from the "user" table. If you have doubts about this, there should be a lot of good material on the internet about the subject. ```

For details about how to implement this in our stack (Postgres + ORM), you can check their docs about relations. Your task now is:

lattaai13 commented 2 hours ago

Hello, I tried to solve the issue.

This is what I did:

Add a new Address model to store user addresses and update the User model to have a one-to-many relationship with addresses.

You can review changes in this commit: https://github.com/lattaai13/Andernial-processo-seletivo-backend-2024-26/commit/c10f01d897292dbb21f2d54c71fe83cec1b7e643.

[!CAUTION] Disclaimer: The commit was created by Latta AI and you should never copy paste this code before you check the correctness of generated code. Solution might not be complete, you should use this code as an inspiration only.


This issue was tried to solve for free by Latta AI - https://latta.ai/ourmission

If you no longer want Latta AI to attempt solving issues on your repository, you can block this account.

Andernial commented 2 hours ago

Finish

taki-tiler-server[bot] commented 2 hours ago

Step 3/3 - Updating "user" and "users" queries

Estimated time: 2 hours

Now that we have the database properly setup with the addresses, we're going to update the two queries: "user" and "users". Now they should also return the addresses.

NOTE: don't forget to update your tests!

After that, open a PR! We could explore it more by creating a mutation to add an address to a user, and also update/remove an existing address. But we think this is enough as an intro for the relation concept.