[Track 9/9] Relations

[taki-tiler-server[bot]]

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:

• CEP (zipcode)
• Street
• Street number
• Complement (optional)
• Neighborhood
• City
• State

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.

[hugoms154]

finish

[taki-tiler-server[bot]]

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 | | | cpf | | | birthDate | | +-------------+--------------+ +--------------+--------------+ | 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 + TypeORM), you can check their docs about relations. Your task now is:

• Create the "Address" entity
• Implement the relation between "User" and "Address"
• After creating the entity, you should update your database. If synchronize is enabled, you just need to run the server again to update.
• Make sure the relation is working by running some test code and adding a user with at least 2 addresses. Check TablePlus to see the table sctructure working as above.
• Open a Pull Request

[hugoms154]

next

[taki-tiler-server[bot]]

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.