I have a migration called CreateItemsTable; I ran that, I have items in that table, now I need to add a new field to the table. I can't just add a field to the migration file and migrate:refresh because I need the data that's in it.
Am I supposed to make another migration for adding a field? That's seems like mess while I'm testing things in development, I might change fields a lot. I'm not sure if migrations are cleaner than just PhpMyAdmin... or maybe I don't understand them?
Yes, each time you need to change a table in some way you'd create a new migration for it. That's the whole point of migrations. When you're developing in a collaborative environment and you pull down some changes from a remote repository, one of the things you should do (if working with a database) is run any migrations that other developers might have created. This keeps your databases in sync.
Sure you might drop and add columns occasionally but it's no big deal.
When you create a table for the first time you are probably using Schema::create(). All subsequent migrations for that table should use Scheme::table(). It accepts the same parameters except it doesn't attempt to create the table first.
Related
I have a started project in Codeigniter. I thought I will use some part of already created sections of similar site. So I have copied the old database and started work.
On that time it has around 40+ tables and has thousands of rows of data.
Then after I setup my environment for this new project, several tables created and all of those used migrations. It's then setup in development environment, so other team members can also work on.
Now I found old users and lots of data that I copied from old project not required
I decided to remove all tables that is not required for current project.
And need to remove all users and related data that was actually came from old project. Now database has 49 tables and I need only around 10 tables for my current project.
Question is Should I use migration to clear an old database?
Should I use migration to remove thousands of old data that are mixed with development data.
Should I use migration to alter several tables where lots of column not required for my current project?
Please provide suggestions
.. Thanks
In Laravel, migrations are there to keep a track of the structure of the database.
If your old database is not defined in migrations, there is no point to create migrations to remove unused tables. You can clean them manually.
But if you have made migrations for that old DB, then you can create new ones to clean it up.
Anything related to the actual data in the database should be placed within seeders nor custom command (e.g. php artisan make:command CleanData)
The reason is that if you ever need to squash your migrations, you will lose any instructions related to data.
Hello everyone
I'm going to try to explain my problem as clear as possible, feel free to ask me more precision if you didn't understand what I meant and forgive my mistakes, English is not my mother tongue.
My goal
I want to start using migrations again because I need to create a new table, after a year where developers of my company bypassed them by creating/deleting/updating tables directly from phpmyadmin.
The things you have to know
The last migration was a year ago, but many tables have been created without migrations since that time.
Why I need your help
I'd like to know what is the best way to start using again migration without losing data or tables, because I'm working on an environment production.
What is the best way to do that ? Keeping the migrations that already exists and just ignoring the tables that have been created ? Deleting all migration files and deleting all the row in the migration table ?
If I delete all the migration files and truncate the migration table, will a php artisan migratewill have any impact on the existing schema ?
What is the best practice ? Should I recreate all the migrations of all the tables of my schema ? Or should I create only one migration with the new table I want to create ?
You could start from scratch by deleting all migrations and truncating the migrations table.
Then take a look at this post to recreate all the migrations for your current database schema.
Laravel keeps track of the migrations using a dedicated table that records when they were applied. When any one migration gets run, it inserts a new record in the table, and if you roll back a migration the corresponding record is deleted. You can therefore prevent undesired migrations from being run by adding them to this table.
My advice would be as follows:
Create the missing migrations
Run them on your local copy to get the database in the required state there
Export the migrations table
Import it to the production database
If you have any additional migrations you want to run after the ones you ran locally, run them in production
I'd definitely be careful to have a dry run beforehand though - perhaps after exporting the migrations, import the production database to your local copy, then import the migrations, and check it there.
I'd also be inclined to take steps to stop people applying changes to the production database directly - it's a very dangerous step that avoids accountability and makes it hard to test your application locally. Perhaps lock down PHPMyAdmin.
Mostly in these cases I try to sync migrations with my table so that I don't lose the current data which is on the database and I know that my migrations are updated .
So I from the first table whatever you have added in your table manually, you have to add that to your migration too .
In this case in future if you need to create a database truncate or anything else you know that your migrations are already up to date .
To be honest the best practice is to make the changes in your migration not in the database so you have not done the best practice so . this is the best practice that even can be done in your case so you make a migration to your project like this :
php artisan make:migration added_photo_to_user_table --table=users
and then in your migration :
public function up()
{
Schema::create('users', function (Blueprint $table) {
$table->text('photo')->nullable;
});
}
then u have to run the command
php artisan migrate
but in your case because you added the fields to the database you don't need to run the last command you just have to make migrations so in future if you want to make update to the database you do it as the best practice and you don't encounter any data lost .
I am using cakephp 3.
I need to run a script for updating the database schema like adding a column or altering it.
I do not wish to use Migrations as it would require me to write scripts for every change.
Is there any other way to alter schema of the database if we are neither using migrations nor making changes to the database manually using cakePHP 3?
You could use the schema system for doing this, which I think would work fine for things like adding user-defined columns. But if you're looking for an easier way to do migrations, you'd need to put that schema-related code somewhere and keep track of which changes have already been made, and then you're basically just re-inventing migrations.
I need to remove a single value from a laravels migration table, but within the database (I use phpmyadmin) I cant edit any data on the table i can click on the table but nothing more theres not even an option to delete the separate fields, does anyone know why this is and furthermore how would i alter the tables.
To prevent any further confusion its the table thats auto generated by laravel and auto updated anytime you run any migrations
It's important to know why you're using migrations. The best benefit of migrations is that you can redeploy an application and the database will have the same structure. This means that if I make a migration, and you deploy my application and run the migration, we both have the same database.
This means when you're using the migrations you have to keep that in mind. When you make a migration you change the database. If you want to change something after that, you'll have to make another migration. If you change the existing migration files or change your database manually the database won't be the same. This means different errors in different environments and alot of other problems you'll face.
So to answer your question, make the changes to your database using another migration.
Some links that can be of help to you understanding this concept:
Why use migrations
Migrations documentation
Try this,
just copy paste migration value which is 2015_12_07..., something like that
and fire query in phpmyadmin as
delete from migrations where migration = 'copy_pasted_string'
I hope this will work
And yes, you can perform all operation on the record by this string.
Please refer to
https://laravel.com/docs/5.3/migrations#dropping-columns
Schema::table('users', function (Blueprint $table) {
$table->dropColumn('votes');
});
The decision I'm trying to make is where I want to do schema changes. I need a schema update to happen in the database, in the model definition, and I'd also like to generate a doctrine migration for that change too. I would really prefer to only have to define schema changes in one place, not three.
Right now I'm thinking of writing all schema changes only as doctrine migrations. I then have a command line tool that runs all pending migrations and does a database->model sync. Is this reliable enough to work? I'm using postgresql if it matters.
The standard flow is to generate an empty doctrine migrations, add the schema changes run the migrations and create your entities. So you'll only need to modify it at 2 places.
This works perfectly with my set-up. Never had any problems with it if you check your down statement at least.