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.
Related
If you're using MySQL setting:
innodb_file_per_table=ON
You free disk space when removing records from tables, but in order to refresh statistics once you a table free space, it's required by MySQL to run ANALYZE TABLE your_table.
I'd like to know if theres's a way to do this refresh via artisan command or some other out-of-the-box way provided by Laravel.
In testing I used the db:clear command in an effort to truncate my data. The command description states:
Clear all tables except for Passport and Laravel tables
However when I ran it, the following was output, and the tables were truncated:
Truncated oauth_access_tokens
Truncated oauth_auth_codes
Truncated oauth_personal_access_clients
Truncated oauth_refresh_tokens
Based on the command description, I was not expecting these tables to be truncated. Is this expectation incorrect? I attempted to find the command in question to see if this was intended functionality, but could not find it in the Laravel source.
Laravel version 8.x
After further investigation into the data after clearing the DB, this appears to have only touched some of the Passport tables. I was not expecting to see any Passport tables in the command output based on the command description, but it seems it does truncate Passport tables that have non-reusable data like access tokens and auth codes. It does keep data for things like clients though.
It is still unclear to me where the command is located, but that was a secondary concern.
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 made a command and registered it in Kernel.php named "offers:update".
This command should do some changes on "offers" table depending on current status of each offer daily at 00:00.
My "offers" table might have above 100,000 rows and i want to do changes in the the most optimized way.
I've read the documentation (v 5.8) and found chunk() method.
Is it enough or there is better idea?
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.