I'm using YII 1.1.12. When I do:
yiic migrate
inside the protected folder of my application, I get told that there is a new migration to be applied. I answer "Yes" so that the migration would be applied. After a while, I get:
*** applied m121220_121256_initialize_database (time: 6.060s)
Migrated up successfully.
All is fine up to this point. Then when I type 'yiic migrate', instead of being told that there is no new migration, I get told that:
Yii Migration Tool v1.0 (based on Yii v1.1.12)
Total 1 new migration to be applied:
m121220_121256_initialize_database
Apply the above migration? (yes|no) [no]:
WhenI check the tbl_migration table, the only thing in there is the base migration. There's nothing aboutinitialize_database.
Any ideas?
Does your migration create the database? If so it might be throwing Yii off, and it's creating the migration structure at the start and then can't insert into, I'm not sure what the behaviour would be.
If m121220_121256_initialize_database is doing any kind of destructive work then it's probably a good idea to use yiic migrate mark 121220_121256 to manually set the database to this migration after you've ran it.
That way you can do further tests to see whether it's a migration bug or something destructive in the migration like dropping/creating a database.
I realised the problem was that the sql commands I was running straight from PHPMyAdmin contained a transaction. When I removed the lines about transactions, the database row in the yii_migration table was inserted successfully. I'm not sure why this should be, but there it is.
Related
I was recently tweaking around with my DB and noticed that I made 5 migrations on top of my existing 2. So 7 in total, m1, m2, ..., m7. From these 5, I only want the latest version. So I was thinking I could remove m3, m4, m5, m6, m7 and migrate again, which will result in m3 that already contains the final version that I'm happy with. Now I have never done this before and was wondering what is the safest way to do it?
I'm using PHPStorm. Could I manually remove them (right click in PHPStorm then Delete) and then go to the command line and do php bin/console doctrine:migrations:migrate? Or do I need to do php bin/console doctrine:schema:update? Or is this really a bad idea?
No, generally you shouldn't do either of those. Let me start by clearing up what seems like a misconception: a migration doesn't contain a full database schema, only the queries necessary to bring the database from one version to the next. This system allows for database changes to be managed and versioned. So you should be starting to see some problems with this:
A migration might depend on a previous one. E.g. v1 adds an entity and v2 adds a new field. If you remove v1, v2 will be broken and needs to be removed as well.
Since a database migration usually goes hand in hand with an object model change, you will have to revert the model as well, otherwise you'll find mapping problems with non existent fields.
This might be acceptable during the design phase when you don't have any functionality yet. You can revert an individual migration using bin/console doctrine:migrations:execute --down <version>. This is usually done while testing changes if adjustments need to be made. But usually when that change hasn't been committed yet.
Doctrine keeps track of migrations using a database table called migration_versions. By naming them with a date, it can order them and apply them sequentially. Whenever a migration is executed, it adds the migration name to this table. When you roll it back, it deletes it from the table, along with the fields in the migration itself. Keep in mind that even though you can rollback a migration, it doesn't mean everything will be as it was. If a migration drops a column, the column will be recreated on rollback, but the data will be lost.
As for "can it be done"? Yes. If you really really want to, have read the documentation thoroughly and are aware of all this.
So, since your question is about merging migrations, let's tackle your actual options:
Could I manually remove them (right click in PHPStorm then Delete) and then go to the command line and do php bin/console doctrine:migrations:migrate?
No, this won't work. migrate will apply available migrations. They won't be any and, as explained, the revisions will still be in the table and its changes applied.
Or do I need to do php bin/console doctrine:schema:update?
This won't do anything either, since it will compare the model with the database and find that they match.
In any case, you will need to revert them first and then create an equivalent one. The command for that is doctrine:migrations:diff. This will compare the model with the schema and generate a migration to get the database in sync. And for this to work you will need to execute --down your migrations first, otherwise they won't be any changes, but potentially losing some data in the process.
If you work in a team, they will be seeing migrations disappear. Some might even be behind in the history and not applied all the migrations. This will soon become a management pain.
There is a rollup command that (with my understanding and never actually used it) cleans stale migrations from the table, dumps a full schema and applies it. This will be your best bet, but be aware that this most like will delete your data.
You could also combine your migrations manually. They are just classes with an up and down methods. Combine all function bodies, apply the cleanup process and call it a day.
Now, if you want to do this it shouldn't be much of a problem. Just replace your outdated versions with your new one and warn everybody about it. But if what you want is to do as they never existed at all and keep a neat commit history, then that's when your teammates will potentially want to kill you, as it will involve rewriting history. When you do that, they will have to rebase all their work.
If you want to do it:
Make backups
Introduce your changes as early as possible to avoid breaks. Is ok if there are some unused fields in the database for a while, until the model commits catch up. If you do it late and some object need it, someone might be forced to create a migration and break yours in the process.
Get it right (preferably on the first try). Don't push until you have tested extensively.
Make backups
Reference for the console commands
There isn't a "safe" way of doing it, but if you haven't deployed the migrations then you can safely throw away a series of auto-generated migrations and regenerate them. Just be careful you don't throw away manual migration SQL at the same time.
Normally during the design stage we will:
Use doctrine:schema:update --force until things are fairly stable
After they are stable, we reset the development database from a snapshot
Run doctrine:migrations:diff and then add manually migration queries where necessary
May be you need to ignore all your migrations and focus on your last state of database schema. If this is what you are wondering to have in final, then you could just hit:
php bin/console doctrine:schema:update --dump-sql to get the corresponding SQL statement, or hit php bin/console doctrine:schema:update --force to apply it actually on database.
In general yes you can.
But you should know about that the Doctrine/Migration save executed migrations in DB . So you should remove unnecessary migration files (possible combine all queries into one), after that update database.
Table name by default "doctrine_migration_version" just delete unnecessary version rows
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 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');
});
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.
I am totally new to FuelPHP, ORM and migrations in general so sorry if I come across like a newbie, but I've been struggling with this for a few hours now so I thought I'd ask for help. I think I'm either doing something wrong or missing something fundamental.
I am trying to create a users model, for simplicity let's say it just has a string representing name.
I was under the impression that using the following two Oil commands would create a users model, and an associated migration which after running would build an associated table:
php oil generate model user name:string
oil refine migrate
This does successfully create the model and migration, but running the second command doesn't build the table in the database.
If I run these commands on the other hand:
php oil generate migration create_user name:text
oil refine migrate
The migration is created and the table is built in my database. I noticed that perpending 'create_' to the migration name made it possible to create the table, whereas leaving it off (i.e php oil generate migration user name:text) doesn't insert the table to the DB. I noticed the generated migrations with and without the 'create_' are significantly different.
So my question ultimately is, how do I create the model, associated migration which creates the table? Or, am I totally misunderstanding something?
Thanks!
If you get 'Already on the latest migration', your migration tracking data is out of sync. Migrations are tracked both in the database (a table called migration) and a config file in your environment folder called migrations.php.
If there is already an entry in one of them, oil will not run it again.
So you can't just delete the table through the backdoor and then run the migration again. You'll have to run a 'migrate:down' to revert the last migration, or if you delete all, also delete the migration table and config file.
Again, credit to Harro Verton on the FuelPHP forums.