In order to start your Laravel based app you have to have your database in order – setup and ready.

Laravel gives you a chance to do two quite useful things:

it will store all your table updates/upgrades in files – each file with its timestamp(see: /database/migrations/ folder)
so anything fgoes wrong, you have a chance to track down since when you have to apply fixes

it allows you to create your database/table on-the-fly without bothering with anything like PHPMyAdmin – this sometimes can be very useful (not that it cannot be done without Laravel, of course, by using PHP/MySQL capacity)

above approach allows you to grab migration files from version control repo (if you work in team) and apply them with easy CLI command (more to come on this subject)

Picture that 2 team members (or more) are trying to update table Tasks.
They create migrate files using CLI

Shell

1

2

3

php artisan make:migration create_tasks_table--create=tasks

which contain PHP classes – something like shown below:

PHP

1

2

3

4

5

6

7

8

9

10

11

12

<?php

useIlluminate\Database\Schema\Blueprint;

useIlluminate\Database\Migrations\Migration;

classCreateTasksTableextendsMigration

{

//migration content goes inside

//this ehere table will be added, edited and dropped

}

As I mentioned already, more will be written about migrating itself later on on this – right after I explain this practical conundrum, you most likely come across more than once.

We synch your local files with version control repo and now, inside of /database/migrations folder we have 2 migration files:

2016_03_27_182158_create_tasks_table

2016_03_27_192624_create_tasks_table

Each of them contains a PHP class: CreateTasksTable – as shown in code above – with all necessary changes to database.

To apply changes to your database using new migration files received from repo you have to run Laravel CLI code:

Shell

1

2

3

php artisan migrate

As you know, PHP does not allow to declare more than one class with a given name.
That is why you have Namespaces to limit possibility of such run-ins.
Also, if you are familiar with Zend, you probably remember these ridiculously long class names. They were that long to avoid fatal run-ins. You may think of them as class names with builtin namespace 😉

Anyway, if you try to run migrate CLI command, you will get an error like this (with your local folder path of course):