i'm using laravel and working on migrations.
I am looking for records of the implementation of migrations. How does Laravel find out how far the migrations have run? Because I have checked that each migraine only runs once and will not run in subsequent commands.
My software has one source and several databases (per user). I would like to know what effect will this have on other users if one of my users executes migraine?
Migrations, once processed are held in the database in a migrations table. If your users have separate databases then they will have their own migrations table. Can't imagine a scenario though where users of the application would be running migrate?
Related
I have two Laravel apps that use the same database. I moved migrations from app 1 to app 2.
Now I want to remove the pending migrations from app 2 due to that I moved the migrations files to it and tables exists in database.
Is any way to remove them from pending execution when php artisan migrate is executed?
Regards
You can add the migrations manually in the migrations table in the database, and that way they will be marked as executed.
Note that i assume both apps do not use the same database migrations table.
I maintain a new but popular open source project based on Laravel 5.4. After a few months, we already have 100+ migrations in the database folder.
In a year from now, we'll easily have more than 1000 migrations with the current rate of features.
Rails has the same concept of migrations, but when migrations are run, they are ran against schema.rb, which is updated after the migrations have been run. This is super nice because for new installations, they don't have to run all those migrations. Only one is necessary.
Is there a way in Laravel to do the same? Reduce the number of migrations after a given period of time, or between major version, have a base schema with only few migrations? Thanks!
I am having a very bad situation here, working on a Laravel 5 project. previously developed by another developer. That developer at start created couple of tables using migration generators and added some columns using migrations. After that, he added table columns straight away using some sql GUI. I was given the sql dump which i imported and set it up on my local machine, now when i created a table using php artisan make:migration create_myTableName_table --create="myTableName" the table migration is created successfully, but, when i did php artisan migrate it's giving me SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'someTable' already exists I checked migrations folder and matched it with current version of someTable and i can see the columns are different, same with other tables aswell.
What should be the best case to handle this in this situation, i want to keep up with Laravel migrations generator so that in future if any other developer want to work on this project he just has to run migration command to migrate database or to create tables or create columns... Should i re-write all migrations ? pleas help. Thanks
Given your situation, I’d put the .sql export in your repository, clear out the old, broken migrations, and create a new one that initially imports the database dump. Then just create migrations as normal going forward.
Quick and dirty?
Delete current migration files. Clear your migrations table and export the whole DB. Put the SQL dump in the repo and instruct other devs to import it before they run php artisan migrate. With the dump imported and migrations table truncated, you can create new migrations with no further collisions with the legacy migrations.
Feeling ambitious?
Use a package like migrations-generator to generate migrations based on your current DB structure. Then, migrate away.
I have been working with Laravel for about a couple of months now - loving it. Have a question about the workflow that is recommended for managing changes to the database.
I have a test database that I used to develop my app, and when I was reasonably happy, I created a production database by copying the structure in phpMyAdmin. I had built the initial database on phpMyAdmin, as I was not familiar with the Laravel Migrations.
Now I am at a point where I better understand the power of Laravel Migrations, and would like to use them going forward to update the test database and move those changes to the production.
What is the course of action for me? Can I delete everything in the app/database/migrations dir and start from scratch? Will there be issues down the line calling php artisan migrate in my test and production environment?
Thanks in advance for the responses!
Short answer: no problems. If you just add/alter/remove tables/columns in the up() and down() methods.
Longer answer: still no problem. As long as you don't drop a table that is not created in an up() method.
But let's say you get to work with another developer, that person also wants to develop on a local DB. But you don't have the migration for it - so the new dev needs to run the initial structure from test DB, and then apply the new migrations.
In that case I would start with 1 big migration where you create all the initial tables, and in the down() the drops of those tables, so the new dev can just run the migrate and start coding.
edit: and after that migration for the initial structure, just add new ones while developing ;)
I'm learning laravel and in most of tutorials they are making migrations using artisan.
I skip that step and I'm working directly on a database.
I don't know for what can a migration be useful.
so the question is: what is exactly a migration?
If you are the lone developer, you may not get much use out of it.
But imagine you have multiple developers each with your app stored locally on their machine. What happens when you need to make an update to the database? You would have to make the update, send the query to each other developer, and they would have to run the query on their machines. Once you get a decent amount of developers making changes to the database, this process can quickly become overwhelming and it's only a matter of time before people start missing the changes.
With migrations, all of the changes are stored as files, so in order for a developer to catch up, all they need to do is fetch the code changes and run php artisan migrate and all the work is done for them. This means all your developers are consistently working with the same database structure.