I'm facing a weird experience with Laravel Migration.
I've run 2 migrations the first one passed in less than second.
The second is taking a long time and still running for more than 10 minutes untill I killed it.
It's not a big deal, just adding 2 columns to a table that contains 23 entries. Yes, only 23 entries.
the query itslef is very simple :
Schema::table('customers', function (Blueprint $table) {
$table->boolean('public')->default(0);
$table->integer('user_id')->nullable();
});
Any clue ? I'm missing anything ?
Is it because I already have 30 columns in the table ?
==== Edit ====
As asked, here are the other migration that passed
class UpdateUsers extends Migration
{
/**
* Run the migrations.
*
* #return void
*/
public function up()
{
Schema::table('users', function (Blueprint $table) {
$table->integer('shop_id')->nullable();
});
}
/**
* Reverse the migrations.
*
* #return void
*/
public function down()
{
//
}
}
the one that is not working
{
/**
* Run the migrations.
*
* #return void
*/
public function up()
{
Schema::table('customers', function (Blueprint $table) {
$table->boolean('public')->default(0);
$table->integer('user_id')->nullable();
});
}
/**
* Reverse the migrations.
*
* #return void
*/
public function down()
{
}
}
Finally, I understand what's going on.
I had some slowness when performing some requests. So I thought about the MySQL serve.
I restarted it and then launched the same migration that used not to work and it went perfect (0.07 seconds).
I think checked and / or restarting the BD server is something to check systematically as well as checking the syntax and table structure.
Cheers
Related
I'm trying to change the data type (from string to boolean) of 5 columns in my database, but it's showing an error that i have no idea what is the meaning.
My migration is this:
<?php
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;
class ChangeFieldDataType extends Migration
{
/**
* Run the migrations.
*
* #return void
*/
public function up()
{
Schema::table('users', function (Blueprint $table) {
$table->boolean('categoria_pneu')->change();
$table->boolean('categoria_dicas')->change();
$table->boolean('categoria_servicos')->change();
$table->boolean('categoria_dicas_gerais')->change();
$table->boolean('categoria_variados')->change();
});
}
/**
* Reverse the migrations.
*
* #return void
*/
public function down()
{
Schema::table('users', function (Blueprint $table) {
$table->dropColumn('categoria_pneu');
$table->dropColumn('categoria_dicas');
$table->dropColumn('categoria_servicos');
$table->dropColumn('categoria_dicas_gerais');
$table->dropColumn('categoria_variados');
});
}
}
The erros that's showing, is this:
I don't know what is the meaning of the error, since i'm trying to change the type to BOOLEAN and not TINYINT (i don't actually know if it's the same...)
I have a migration that updates a table to add a new column:
<?php
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;
class AddStringNormalizationSettingToDataSourcesTable extends Migration
{
/**
* Run the migrations.
*
* #return void
*/
public function up()
{
Schema::table('data_sources', function (Blueprint $table) {
$table->char('do_string_normalization', 1)->default('n')->after('vat_mode');
});
}
/**
* Reverse the migrations.
*
* #return void
*/
public function down()
{
Schema::table('data_sources', function (Blueprint $table) {
$table->dropColumn('do_string_normalization');
});
}
}
This works fine, the column is created and all existing rows have the value 'n'. However I would like the default to actually be 'y' so new rows will get created with the value 'y' unless otherwise specified.
How would I specify a different value for the default after the column is created and the existing rows are updated?
I have tried adding a line after the original column insert:
$table->char('do_string_normalization', 1)->default('n');
$table->char('do_string_normalization', 1)->default('y')->change();
But it throws the following exception when running the migration:
Unknown column type "char" requested. Any Doctrine type that you use has to be registered with \Doctrine\DBAL\Types\Type::addType(). You can get a list of all the known types with \Doctrine\DBAL\Types\Type::getTypesMap(). If this error occurs during database introspection then you might have forgotten to register all database types for a Doctrine Type. Use AbstractPlatform#registerDoctrineTypeMapping() or have your custom types implement Type#getMappedDatabaseTypes(). If the type name is empty you might have a problem with the cache or forgot some mapping information.
Googling the string "Unknown column type "char" requested" leads to an issue on the laravel framework's tracker where it is suggested that you can not modify a newly created column in the same migration. I could, I guess, create another migration to change the default. But I would rather not have two migrations just to add a single file if possible. Is it?
Update
After further testing (with multiple migration files and two Schema::table() calls) the issue seems to actually be that doctrine (the package from Symphony used by Laravel to make modifications to existing tables) does not support the char datatype. So this works fine:
public function up()
{
Schema::table('data_sources', function (Blueprint $table) {
$table->string('do_string_normalization', 1)->default('n');
});
Schema::table('data_sources', function (Blueprint $table) {
$table->string('do_string_normalization', 1)->default('y')->change();
});
}
As does this:
public function up()
{
Schema::table('data_sources', function (Blueprint $table) {
$table->boolean('do_string_normalization')->default(false);
});
Schema::table('data_sources', function (Blueprint $table) {
$table->boolean('do_string_normalization')->default(true)->change();
});
}
But this throws up an exception:
public function up()
{
Schema::table('data_sources', function (Blueprint $table) {
$table->char('do_string_normalization', 1)->default('n');
});
Schema::table('data_sources', function (Blueprint $table) {
$table->char('do_string_normalization', 1)->default('y')->change();
});
}
If I understand you correctly, you have an existing table with many rows in it already, and you would like to add a column to this table. For all existing rows you would like the value of the new column to be set to 'n', and for all new rows being added to the table you would like the default to be 'y'.
You can achieve using a raw db statement. This is necessary since there are likely compatibility issues between database types that prevents Doctrine from being able to support changing char type columns.
/**
* Run the migrations.
*
* #return void
*/
public function up()
{
Schema::table('data_sources', function (Blueprint $table) {
$table->char('do_string_normalization', 1)->default('n')->after('vat_mode');
});
// Note this may not be compatible with all DBs
DB::statement('ALTER TABLE data_sources ALTER do_string_normalization SET DEFAULT "y";');
}
I created the settings table via a migration and implemented a SettingsServiceProvider (based on this post Laravel - Set global variable from settings table). Now it says that the base table can't be found. Of course not, because I need to run the migration first.
[Illuminate\Database\QueryException] SQLSTATE[42S02]: Base table or view not found: 1146 Table 'db.settings' doesn't exist (SQL : select value, name from settings)
Any ideas what to do? I course I could create the table manually but this would destruct the ideas of migrations...
Any help would be appreciated. I'm using Laravel 5.3.
Update 25/11/2016 - added code snippets
Service Provider
<?php
namespace App\Providers;
use Illuminate\Support\ServiceProvider;
class SettingsServiceProvider extends ServiceProvider
{
/**
* Bootstrap the application services.
*
* #return void
*/
public function boot()
{
config()->set('settings', \App\Setting::pluck('value', 'name')->all());
}
/**
* Register the application services.
*
* #return void
*/
public function register()
{
//
}
}
Migration
<?php
use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
class CreateSettingsTable extends Migration
{
/**
* Run the migrations.
*
* #return void
*/
public function up()
{
Schema::create('settings', function (Blueprint $table) {
$table->increments('id');
$table->string('name');
$table->integer('value');
$table->timestamps();
});
}
/**
* Reverse the migrations.
*
* #return void
*/
public function down()
{
Schema::dropIfExists('settings');
}
}
Here's some sample code:
/**
* Run the migrations.
*
* #return void
*/
public function up()
{
Schema::table('orders', function(Blueprint $table)
{
$table->integer('user_id')->unsigned()->nullable()->change();
});
}
/**
* Reverse the migrations.
*
* #return void
*/
public function down()
{
Schema::table('orders', function(Blueprint $table)
{
$table->integer('user_id')->unsigned()->change();
});
}
The first part works great. Basically, I'm taking an existing user_id column and altering it so that it's nullable. Works perfectly.
However, when I run migrate:rollback, the column stays nullable and I have an imperfect up/down migration relationship. What's the best practice solution for resolving this?
The only way I would suggest doing this is to run the DB::statement() method. Something like the following
public function down() {
DB::statement('ALTER TABLE `orders` MODIFY `user_id` INTEGER UNSIGNED NOT NULL;');
}
I'm trying to learn Laravel. I'm following the Quickstart documentation but have gotten into a problem with Migrations. I'm at this step: http://laravel.com/docs/quick#creating-a-migration
When I run the command php artisan migrate, the command line displays the following:
c:\wamp\www\laravel>php artisan migrate
Migration table created successfully.
Migrated: 2013_09_21_040037_create_users_table
In the database, I see a migrations table created with 1 record. However, I do not see a users table. So, I can't continue on to the ORM portion of the tutorial.
Any ideas what I might be doing wrong? Why isn't the users table getting created?
EDIT 1 (original migration file):
<?php
use Illuminate\Database\Migrations\Migration;
class CreateUsersTable extends Migration {
/**
* Run the migrations.
*
* #return void
*/
public function up()
{
Schema::create('users', function($table)
{
$table->increments('id');
$table->string('email')->unique();
$table->string('name');
$table->timestamps();
});
}
/**
* Reverse the migrations.
*
* #return void
*/
public function down()
{
Schema::drop('users');
}
}
The updated Laravel should use Blueprint for database schema creation.
So try to change your user migration file content like this,
<?php
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
class CreateUsersTable extends Migration {
/**
* Run the migrations.
*
* #return void
*/
public function up()
{
Schema::create('users', function(Blueprint $table) {
$table->integer('id', true);
$table->string('name');
$table->string('username')->unique();
$table->string('email')->unique();
$table->string('password');
$table->timestamps();
$table->softDeletes();
});
}
/**
* Reverse the migrations.
*
* #return void
*/
public function down()
{
Schema::drop('users');
}
}
Then run,
php artisan migrate:rollback
and then migrate again.
Read the API documentation here http://laravel.com/api/class-Illuminate.Database.Schema.Blueprint.html
I faced the same problem, after searching at Laravel documentation (link to documentation), i found an artisan command that resolve it :
php artisan migrate:refresh
The migrate:refresh command will roll back all of your migrations and then execute the migrate command. This command effectively re-creates your entire database