Package Data | |
---|---|
Maintainer Username: | orangehill |
Maintainer Contact: | jeffrey@laracasts.com (Jeffrey Way) |
Package Create Date: | 2016-01-25 |
Package Last Update: | 2017-12-14 |
Home Page: | https://laracasts.com/lessons/faster-workflow-with-generators |
Language: | PHP |
License: | MIT |
Last Refreshed: | 2024-12-24 03:00:13 |
Package Statistics | |
---|---|
Total Downloads: | 9,514 |
Monthly Downloads: | 0 |
Daily Downloads: | 0 |
Total Stars: | 0 |
Total Watchers: | 4 |
Total Forks: | 1 |
Total Open Issues: | 0 |
If you're familiar with my Laravel 4 Generators, then this is basically the same thing - just upgraded for Laravel 5.
L5 includes a bunch of generators out of the box, so this package only needs to add a few things, like:
make:migration:schema
make:migration:pivot
make:seed
With one or two more to come.
composer require laracasts/generators --dev
You're all set. Run php artisan
from the console, and you'll see the new commands in the make:*
namespace section.
composer require laracasts/generators --dev
You'll only want to use these generators for local development, so you don't want to update the production providers
array in config/app.php
. Instead, add the provider in app/Providers/AppServiceProvider.php
, like so:
public function register()
{
if ($this->app->environment() == 'local') {
$this->app->register('Laracasts\Generators\GeneratorsServiceProvider');
}
}
You're all set. Run php artisan
from the console, and you'll see the new commands in the make:*
namespace section.
php artisan make:migration:schema create_users_table --schema="username:string, email:string:unique"
Notice the format that we use, when declaring any applicable schema: a comma-separate list...
COLUMN_NAME:COLUMN_TYPE
So any of these will do:
username:string
body:text
age:integer
published_at:date
excerpt:text:nullable
email:string:unique:default('foo@example.com')
Using the schema from earlier...
--schema="username:string, email:string:unique"
...this will give you:
<?php
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
class CreateUsersTable extends Migration {
/**
* Run the migrations.
*
* @return void
*/
public function up()
{
Schema::create('users', function(Blueprint $table) {
$table->increments('id');
$table->string('username');
$table->string('email')->unique();
$table->timestamps();
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::drop('users');
}
}
When generating migrations with schema, the name of your migration (like, "create_users_table") matters. We use it to figure out what you're trying to accomplish. In this case, we began with the "create" keyword, which signals that we want to create a new table.
Alternatively, we can use the "remove" or "add" keywords, and the generated boilerplate will adapt, as needed. Let's create a migration to remove a column.
php artisan make:migration:schema remove_user_id_from_posts_table --schema="user_id:integer"
Now, notice that we're using the correct Schema methods.
<?php
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
class RemoveUserIdFromPostsTable extends Migration {
/**
* Run the migrations.
*
* @return void
*/
public function up()
{
Schema::table('posts', function(Blueprint $table) {
$table->dropColumn('user_id');
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::table('posts', function(Blueprint $table) {
$table->integer('user_id');
});
}
}
Here's a few other examples of commands that you might write:
php artisan make:migration:schema create_posts_table
php artisan make:migration:schema create_posts_table --schema="title:string, body:text, excerpt:string:nullable"
php artisan make:migration:schema remove_excerpt_from_posts_table --schema="excerpt:string:nullable"
Now, when you create a migration, you typically want a model to go with it, right? By default, we'll go ahead and create an Eloquent model to go with your migration. This means, if you run, say:
php artisan make:migration:schema create_dogs_table --schema="name:string"
You'll get a migration, populated with the schema...but you'll also get an Eloquent model at app/Dog.php
. Naturally, you can opt out of this by adding the --model=0
flag/option.
For a specific filename, use --filename option:
php artisan make:migration:schema create_doge_table --filename=2016_01_27_090200_create_doge_table.php
If you wish to specify a different path for your migration file, you can use the --path
option like so:
php artisan make:migration:schema create_dogs_table --path=\database\migrations\pets
If you wish to drop a table from the DB you can use the "drop" keyword.
<?php
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
class DropOnionsTable extends Migration
{
/**
* Run the migrations.
*
* @return void
*/
public function up()
{
Schema::drop('onions');
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::create('onions', function (Blueprint $table) {
$table->increments('id');
$table->string('origin');
});
}
}
Don't forget to submit your columns as well for the down method! Also pay attention that if you try to drop a table which has a foreign key attached, your migration will fail at runtime!
There's also a secret bit of sugar for when you need to generate foreign constraints. Imagine that you have a posts table, where each post belongs to a user. Let's try:
php artisan make:migration:schema create_posts_table --schema="user_id:integer:foreign, title:string, body:text"
Notice that "foreign" option (user_id:integer:foreign
)? That's special. It signals that user_id
should receive a foreign constraint. Following conventions, this will give us:
$table->integer('user_id');
$table->foreign('user_id')->references('id')->on('users');
As such, for that full command, our schema should look like so:
Schema::create('posts', function(Blueprint $table) {
$table->increments('id');
$table->integer('user_id');
$table->foreign('user_id')->references('id')->on('users');
$table->string('title');
$table->text('body');
$table->timestamps();
);
Neato.
So you need a migration to setup a pivot table in your database? Easy. We can scaffold the whole class with a single command.
Available arguments and options:
tableOne
- first table nametableTwo
- second table name--action
- action (create,drop), default: create--columnOne
- field name for the first pivot table column (related to the first table)--columnTwo
- field name for the second pivot table column (related to the second table)--path
- path for the migration file--filename
- name of the migration file--tableName
- name of the pivot table--className
- name of the migration class--useForeignKeys
- create foreign keys on the pivot table (default: true)php artisan make:migration:pivot tags posts
Here we pass, in any order, the names of the two tables that we need a joining/pivot table for. This will give you:
<?php
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
class CreatePostTagPivotTable extends Migration {
/**
* Run the migrations.
*
* @return void
*/
public function up()
{
Schema::create('post_tag', function(Blueprint $table)
{
$table->integer('post_id')->unsigned()->index();
$table->foreign('post_id')->references('id')->on('posts')->onDelete('cascade');
$table->integer('tag_id')->unsigned()->index();
$table->foreign('tag_id')->references('id')->on('tags')->onDelete('cascade');
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::drop('post_tag');
}
}
Notice that the naming conventions are being followed here, regardless of what order you pass the table names.
php artisan make:seed posts
This one is fairly basic. It just gives you a quick seeder class in the "database/seeds" folder.
<?php
use Illuminate\Database\Seeder;
// composer require laracasts/testdummy
use Laracasts\TestDummy\Factory as TestDummy;
class PostsTableSeeder extends Seeder {
public function run()
{
// TestDummy::times(20)->create('App\Post');
}
}