I already read Running one specific laravel 4 migration (single file) but this doesn't give me the answer.
I want to know whether there is a way to run the command so that it just executes the next, and just this one migration.
I have got 10 files in my Migrate-Folder. 7 of them are migrated already. Now I found that while I created the 3 new ones and run the command, they are all executed.
The problem is that in the database 'select * from migrations' they show up in one batch and not in separate ones. This means that if I just want to rollback one step, we are back to step 7 and not 9 - what I want.
This is confusing sometimes as I want to rollback one step at a time and not rollback all the steps of one batch.
I know I could move the files in another folder and just leave one to run migrate. Then move the next one and migrate again but this is very inconvenient - what happens if by accident i move and migrate step 10 before step 9.
Anybody knows an answer to this?
In laravel 5.4 you can:
php artisan migrate --step
When you execute the command like this you can roll-back every migration individually afterwards by using the default "php artisan migrate:rollback" without specifying how many steps to rollback.
I don't know of a way to migrate forward one at a time. But you can roll migrations back one at a time like this:
php artisan migrate:rollback --step=1
A bit of a hack, but you could run artisan migrate to run all the migrations, then the following SQL commands to make it look like the migrations were run one at a time:
SET #a = 0;
UPDATE migrations SET batch = #a:=#a+1;
That will change the batch column to 1, 2, 3, 4 .. etc. Add a WHERE batch>=... condition on there (and update the initial value of #a) to only affect certain migrations.
Then you can artisan migrate:rollback as much as is required.
The problem is that in the database 'select * from migrations' they show up in one batch and not in separate ones. This means that if I just want to rollback one step, we are back to step 7 and not 9 - what I want.
It's not enormously ideal, but after running them you can adjust the batch values on each migration in the database table to be separate numbers. php artisan migrate:rollback takes the MAX() batch value and rolls all of its migrations back.
Related
I am using Laravel with the project I am currently working, the question above is one of the necessary thing that needs to be implement on the project.
So there should be a column that needs to reset everyday for all users and this project may contain hundreds or thousands of users and what should be the best way to do it that will not cause performance issues or server overloading.
I wanted to use Laravel's own scheduling but I not sure if this is quite the right thing to do.
Please help :)
You should create a job and schedule a command for this. So, with command even if you have to reset the column manually you can just run this command.
So, what you would do is:
php artisan make:command ResetColumnCommand
and, to generate a job:
php artisan make:job ResetColumnJob
and then, inside the job write the logic which would be similar to this:
$query = SomeModel::query();
$query->chunk(100, function($data) {
$data->update([
// Set the column to null
]);
});
Since, you're sure that there can be alot of records, you should definitely use chunk in order to reduce your memory usage.
NOTE: If you're applying any condition before chunk on a column. e.g: You want only records where that column is not already null then you should use chunkById instead of chunk because there are some issues that can be encountered with chunk and unexpected results.
i have telescope in my Laravel setup, I forgot that I have it and forget to prune it daily. So it accumulated a huge data already it has 28million entries and it is taking 30GB worth of space.
I tried to use both php artisan telescope:clear and php artisan telescope:prune commands but I was having a timeout error because of the large dataset.
How can I clear Laravel Telescope?
three tables that handle telescope operations namely —
telescope_entries, telescope_entries_tags, and telescope_monitoring
in your database run these queries to empty tables
TRUNCATE TABLE telescope_entries;
TRUNCATE TABLE telescope_entries_tags;
TRUNCATE TABLE telescope_monitoring;
You can first run php artisan telescope:clear and then optimize the telescope_entries table optimize table telescope_entries;
As you have lot of data it might take some time to process.
My reasoning, you can skip to below if not interested
I understand how the general procedure of migrations work and the purpose they serve, and very happy to use them in the way that is expected, that is by adding and removing fields as nessesary throughout the applications life.
My query is that at the very beginning of a project I rarely know many of the fields I will need in a given table, and at the very early stages of my projects I want to get the main features and relationships set up, and maybe just use some dud fields before the client makes up their minds on things.
The bottom line is it hurts my OCD knowing there are extra migration files sitting there that potentially look nothing like v1.0 of the project... once im at v0.5 I may decide im far enough along to start properly managing migrations.
Thats my thoughts, but here is the question:
What is the cleanest steps to reuse the same migration script again and again in the early stages of a project while there is no worry about loss of data or rolling back.
Just to add to this i would not want to refresh the entire migration because I would really prefer to keep any data I am playing around and especially the user table for staying logged in to the backend etc.
Would it be wrong to do this:
Could I just remove the migration row in the table, then run the migration?
This feels like it would have side effects, and possibly screw up rolling back, is that the case? What part does the migration table play, as this seems to work in practice?
Final words
Please bear in mind this is just a concept I'm trying to get my head around. If its absolutely bad practice no matter the circumstance I can accept it!
Edit:
Create a new seeder with php artisan make:seeder UserSeeder
Edit the seeder to "seed" the necessary data. Ex:
DB::table('users')->insert([
'name' => 'John Doe',
'email' => 'johndoe#example.com',
'password' => Hash::make('password'),
]);
Then call the built-in artisan function php artisan migrate:fresh --seed which will drop all tables and re-run all of your migrations, then seed your data with your seeders.
You can read more about this process here.
Original:
If you plan to support a live application in the long run, chances are you will have very many of these separate migration files that will still hurt your OCD every time you make a new one. It happens to me every time I create a new one migration to alter a table, haha.
However, in development I can understand your point if you're working on a private codebase and no other developers will be trying to keep up with your changes. If you do, any changes you make to the old migration files will be very tough for them to mimic as the migrations table keeps track of what migrations need to be run (if any), so if someone else tried to migrate after you've changed a previous migration, nothing would happen.
What I would do, is either set up a database seeder in Laravel so you can quickly reseed the data in the table if you rollback a migration, or get a sql dump of your table and reinsert it after you've migrated again.
Another thing you could consider is, not to worry about the migrations directory at this point in development and once you're ready to deploy or push, go through your table alterations and kind of "refactor" them into your desired migrations. But definitely run some thorough testing after this to ensure you're not missing any columns or alterations.
Let's say I have migrations script from V1_1 to V1_300 - it is quite a huge number and takes very long period of time. But from time to time there is a release - can I, from the point of flyway, somehow merge all those migrations so:
All migrations from V1_1 to V1_300 will be in one file (for instance: V2_1)
Amount of time taken by these migrations will drop
Checking for overlaps manually is really time-consuming. Thank you in advance for your answers.
We had the same problem on my project and decided to do a roll up of versions already deployed to production. To roll up incremental changes into 1 file, I ran the migration from scratch in a database then dump (export) back the whole database in 1 SQL file.
I named the file using the last version of the migration. In your case V1_300__rollup.sql. Then you can continue adding new versions: V2_1, V2_2, etc. and repeat when you want to roll up.
I use Entity framework 5 code first with enabled migrations. I made many changes to my model classes and now I have too much migrations classes because after every change I updated the database.
Now I want to merge all my updates to get one "initial class" or 2 so that I could run the update-database command only once if I have to create my database again.
Is that possible with no code (too heavy), I mean with a command for instance ?
Thanks.
The solution is based on whether you want to keep existing data in databases (if you have production databases this is definitely a must) or you can simply drop your database.
I. Cuurrent database can be droped
First you need to delete all migration steps and delete your current database then run the command
add-migration Initial
This way you will have only one migration step instead of a lot.
II. Data must be kept
First create a backup of the current database (that is set as the default database in your solution), then drop the database so when you run the add-migration command the Entity Framework will think that no migrations were applied yet.
After this do the steps as described in the first part and then you will have only one migration step named Initial. After this run the
update-database
command which will create a database matching your current model however only with one row in the __MigrationHistory table. Save this row from the __MigrationHistory table.
Now you can restore the database you've just backed up, delete all rows in the __MigrationHistory table and insert that one row you have saved before. After this the Entity Framework will correctly think that the database and your model is up-to-date and that this was only achieved by running the migration step initial and this way you can keep all your data.
Of course for doing this to multiple databases you only need to do these steps once and for the other databases you just need to delete the current rows in the __MigrationHistory table and insert the new row for the Initial migration step.