3 => Modelling The Applications Data

Before attempting to do any development work it will be helpful to understand the requirements of the application in terms of the data it will need to function. This blog entry will provide an overview of how the data are planned to be organised.

Creating The Models

Now that the datas layout and relationships have been defined I can continue forward, figuring out how Eloquent ORM models work. First I have got to set my relationships in my model, to do this we use one of the built in Eloquent ORM methods. The type of relationship will dictate which function is used. All of my models boilerplate code was generated using the following Artisan command. The -c flag at the end creates a controller for the model as well, reducing the amount of code I am required to write when it comes to managing the controllers logic.

User Relationships

Each user can have multiple boards

Each user can have one custom avatar ( if not the default is used )

Board Relationships

Each board must belong to one user. 

Each board can have multiple columns

Each board must have a tag

Column Relationships

Each column must belong to one board 

Each column can contain multiple tasks in it

Task Relationships

Each task must have one column

Tags Relationship

Each tag can be associated with many boards.

This is where things get a slightly more complicated. Many to many relationships require pivot tables, if you'd like to read more about pivot tables & many to many relationships I find this a good resource, but luckily Laravel can handle this for us relatively easily.

The Board model needs to understand that theres a pivot table so we can do this with :

And the Tag model needs to understand the same, so its the same thing but a different argument passed into belongsToMany :

Database Migrations

Create Users & Boards table migrations

Now that the applications relationships have been modelled it is time to build the tables in the database. These tables can be generated using Laravels artisan migrations. This is yet another instance of the artisan command proving itself to be extremely useful by generating scaffolding code. 

The following is a segment of code taken from our users migration that generates the users table.

This table does not contain any foreign keys so I have included the following example which shows the migration for creating the boards table. As shown in the image the foreign key contains a delete rule and specifies which primary key the foreign key is referring to and in which table. This configuration will be used when generating the tables, setting foreign key constraints while doing so.

To create our column in the database that contains our foreign keys we need to use $table->foreignId('name_of_column') where in this instance the name of the column is 'user_id'. The application then needs to know which value it is referencing and from which table. Here the file is referencing the id column contained in the users table.

The previous pattern has been repeated for the columns table and the tasks table so I will not show them because it is repetitive and the first example shows the core of the process.

Migration Issues

While performing my applications database migrations I ran into one problem that stopped me from progressing me for some time. Debugging this issue required some reading on Stack Overflow as I was not able to find the cause in the official documentation.

When migrating my database my application would throw the following error

This error was telling me that my database was attempting to add a foreign key constraint that referred to a table that was yet to be created, meaning it was bound to crash every time I ran the migration. After reading I learned that Laravel performs its database migrations in the the order of the date specified in the filename ( which is likely the order your code editor displays them by default ). I had to manually modify the time value on the create_tags_table.php file so that it would be above the create_boards_table.php file. In hindsight I don't believe it is the most elegant solution but it did have the intended effect. 

There is likely a way to perform this programmatically however the workaround I used meant this was not necessary in this instance. If I were building the application again I would keep an eye out for this type of issue from the start and take more care when creating my migration files. The following image shows the order of execution of the migration files.

Concluding Remarks

Laravel makes the creation of models easy with its artisan console command. Constructing relationships is a streamlined process that requires minimal code due to Eloquent ORM, the library that comes with Laravel for building these relationships. Once again the framework does a fantastic job of abstracting implementation details away from the developer, allowing them to work on functionality as opposed to wasting time worrying about configuration issues. Eloquent ORM also makes fetching related database entries easy, with the added benefit of making the method names customisable.