I have table named "user_table" has certain columns and table has filled with data. I want to add some more columns. So how can I migrate that new schema in Laravel without loss of existing data. Even I can not do rollback because when I will do then all stored data will be deleted. So, can somebody please help me to solve this issue ?
You can create new table columns in migrations without loss of data. If you alter a column or drop a column, then of course you will manipulate existing data. As long as you are only adding new columns, then you can run
php artisan make:migration alter_my_table_add_columns
and update your existing schema. Then you can safely run
php artisan migrate
In your new migration you would then add:
Schema::table('my_table', function ($table) {
$table->string('my_new_column');
});
See: https://laravel.com/docs/master/migrations#creating-columns
Related
I have this Laravel's migration create Shema for an standard pivot table:
Schema::create('c_l', function (Blueprint $table) {
$table->foreignId('country_id')->constrained()->onDelete('cascade');
$table->foreignId('language_id')->constrained()->onDelete('cascade');
$table->unique(['country_id', 'language_id']);
});
That creates the «c_l» pivot table, but when I go to check the table structure in phpMyAdmin (Maria DB), I get the following:
Where I am missing «c_l_country_id_foreign» in the indexes section.
So I go to check the relations view, where I find:
It seems that both FKs are present.
I am wondering if this difference
is some kind of presentation issue of phpMyadmin with no effects in
operation, or if instead,
can result in a hidden non-checking of the «country_id» FK
constraint, or
can slow down when fetching the database by «country_id», or
other
Thanks for your help in advance!
I've been reading the documentation, but I still have some doubts about creating migrations. On my project, I ran the migrate command to create Laravel's default tables (users, password_resets and migrations). Now I want to, one by one, create the migrations for the remaining tables I have planned on my EER diagram. My doubts are the following:
I can use the php artisan make:migration create_new_table to create a new migration and the --create=tablename complement is used to create a new table.
Will --create=tablename immediately create an empty the table on the DB?
Since I already have three tables, should I use --create=tablename for every new one?
After writing all the code, the migrate command will run all my migrations. Do I use this command after I've written migrations for all tables? Will running it again overwrite tables I already have on the DB?
It's probably basic stuff, but I want to be sure before going forward.
Will --create=tablename immediately create an empty the table on the DB?
No, table will be created when you run php artisan migrate. It will create a new migration with "boilerplate" for tablename. In this case, this will be added to the migration file:
Schema::create('tablename', function (Blueprint $table) {
$table->increments('id');
$table->timestamps();
});
Since I already have three tables, should I use --create=tablename for every new one?
It's really just a helper method for the boilerplate. So if you're creating a new one, it will make it easier.
Personally, I prefer creating migrations with php artisan make:model -m SomeModel, which will create the model and a boilerplate migration (because of -m option).
For example, if you run php artisan make:model SomeModel -m, it will a) create a model named SomeModel b) create a boilerplate migration (called somethinig like timestamp_create_some_models_table) with:
Schema::create('some_models', function (Blueprint $table) {
$table->increments('id');
$table->timestamps();
});
I like it because it's easy to stick to Laravels conventions this way (tables in plural, models in singular).
You can also add a namespace to the Model with the command. For example if you have your models in app/Models directory, you'd write php artisan make:model -m Models/SomeModel instead.
After writing all the code, the migrate command will run all my migrations. Do I use this command after I've written migrations for all tables? Will running it again overwrite tables I already have on the DB?
Laravel creates an SQL table specifically for logging which migrations have already run. It will not run the same migration twice, no matter how many times you execute php artisan migrate. Unless you roll them back with some command.
If a table already exists, it will just throw an SQL error saying, can't create a table, since it already exists.
there's no need to supply the table name, so this question is moot
No, you do not need to do this, see 1
migrate saves the name of each migration file in the migrations table and assigns it a batch id. Each subsequent migrate command will check for the existence of all file names in the table, and if they aren't present, will add it to the current batch before running the migrations defined within said file
I am working on such application where table audit should perform to make revision of updated records. Let's say for example I have to log each field update in Users update.
I wants to create clone of existing user table by
CREATE TABLE users_audit LIKE users;
My main question is,
Is there any alternative way or provision in Laravel migration to create table from existing table ?
I know we can run raw sql query in migration up/down method using \DB::raw();
But it would be helpful if any helper function available to create table from existing table like, create or table
Yes, you can, see the below link
Click this link
This statement is used to execute raw queries
DB::statement('CREATE TABLE tablename LIKE existingtablename');
Suppose I have a table named "foo" with data and also contains foreign key. Now I want to create a column named "description" in this table. Without reset or rollback how to migrate this table?? Because If I reset or rollback the table then all data will be lost.
As per the docs, you just need to create a separate migration to create the new column.
Create the migration
php artisan make:migration add_description_to_foo
Then just set the migration up with the details you want to add, e.g:
Schema::table('foo', function ($table) {
$table->text('description');
});
Then you can just migrate it:
php artisan migrate
This will allow you to add a column without resetting or rolling back your tables, and thus prevent you from losing your data.
Let's start with your schema. Your table name is foo. You want to add a description column to your foo table without losing existing data. You need to create a new migration for this change.
php artisan make:migration add_columns_to_foo_table --table=foo
A new migration file will be created in your migrations directory. Open it and change it like this:
Schema::table('foo', function ($table) {
$table->text('description');
});
Save it and then run
php artisan migrate
description column will be created immediately without losing your old data as last column. In case you want to reposition your description column you need to use after (in case of MySQL) like this:
Schema::table('foo', function ($table) {
$table->text('description')->after('another_column');
});
Hope you got it.
You will find more details here: https://laravel.com/docs/5.3/migrations#creating-columns
I have a create_users_table at the top and with foreign key to roles table but the location of roles table is at the bottom of create_users_table. So what happen is the create_users table can't see the roles table because it's not yet created. See attached image:
Do I need to recreate a users table so that it will come up below to roles table?
Do I need to recreate a users table so that it will come up below to
roles table?
You can't add a foreign key to a table that does not yet exist. If you want to manage your database through migrations, you do need to put them in the right order.
However, you can also add it as a separate migration, so that you have
create users table
create roles table
alter users table to add role_id field and foreign key
That way you don't have to rearrange existing migrations if you e.g. need to make changes to the database mid-project.
if its just a beginning of the project and if you are not using database migrations versioning yet you could just rename the datetime timestamp at migrations filename to rearrange the migrations. something like this would rearrange migrations to the required order. see i changed the year of 2016_08_13_001252_create_roles_table.php to 2014_08_13_001252_create_roles_table.php.
2014_08_13_001252_create_roles_table.php
2014_10_12_000000_create_users_table.php
2014_10_12_100000_create_password_resets_table.php
2016_08_08_005720_create_messages_table.php
migrations run in the datetime order of the filenames. Only the new migrations are run at each run. so, if you bring such changes to the files like renaming the file you need to drop database and create again, then run the migrations.
sometime after doing this you might need to run following commands in the project
composer dump-autoload and/or php artisan clear-compiled.
if you are running the migrations verisoning?
migrations are something related to databases and its not meant for dropping all the tables and recreating each and every time when you need to bring a change. If the database is live or if you have completed major database design you could use versioning. one of the purpose of migrations made in that way (datetime order and only new ones are migrated each time) is that only changes are brought to the old migrations created.