I know that I can run specific migrations using execute with up / down and version number, ie
doctrine:migrations:execute YYYYMMDDHHMMSS --down
My question then - is there an easier way to simply run the next or previous migration without having to look up version numbers?
Ideally I would like something like
doctrine:migrations:execute --down n
Where n is the number of migrations to run from current in the specified direction.
(same idea as rake db:rollback STEP=n)
Closest thing to what I was looking for is:
doctrine:migrations:migrate prev
doctrine:migrations:migrate next
These cannot be used in conjunction with n though, so if you want to do more than 1 you need to use doctrine:migrations:migrate with the version number you want to go to.
i usually just call status, which shows if there any new ones. If so then I call migrate, and it runs all the new ones. See Docs here http://docs.doctrine-project.org/projects/doctrine-migrations/en/latest/reference/introduction.html
Related
I've a code base written in Laravel 9 which targets to execute multiple requests to one API with 1000 different API keys + API secrets. Is there a way to actually do this simmultaniously and not one after another ?
I've come up to this thread Laravel Commands, Pthreads and Closure but the answer there doesn't look like it is wokring, in my opinion it shows that everything is kinda executing at the same time because there is sleep(rand(1,3)) inside the OperatorThreaded class.
Any idea ?
A Laravelly way is to do it like so:
Create a RequestYourApi Job (php artisan make:job RequestYourApi or make a class yourself inside App\Jobs).
Dispatch any amount of jobs using RequestYourApi::dispatch([/* args */]) (the arguments will be passed to the constructor of this class, and the job will be put into the queue, see https://laravel.com/docs/9.x/queues)
Run multiple workers using for instance Supervisor (or Laravel Horizon): php artisan queue:work (use --help to see additional options)
Scale up/down your workers depending on how fast you need to process things.
I tried to run a specific migration table from the controller using the following code
Artisan::call ("migrate:refresh --step=14");
but it does not refresh table 14, on the other hand it refreshes all the tables
.. ,
any suggestion !!
That is the purpose of migrate:refresh. It rolls back the migrations and then runs them:
The migrate:refresh command will roll back all of your migrations and
then execute the migrate command. This command effectively re-creates
your entire database
You may roll back and re-migrate a limited number of migrations by
providing the step option to the refresh command. For example, the
following command will roll back and re-migrate the last five
migrations
If you want to run run a specific migration the command would be:
migrate --path=/database/migrations/my_migration.php
This does however not sound like the best way to achieve whatever you are trying to achieve. Without further information it's hard to suggest an alternative plan for how to achieve this.
Edit: If you are trying to insert pre-defined data into a table you should look into using Database Seeders which sound much more to be what you are looking for.
I am working with Symfony and Doctrine for the first time. I am curious: Is there a simple way to reverse a set of changes generated via a single running of the doctrine:generate:entity command?
I don't have any specific reason (yet) for asking this. I just imagine that it could potentially be helpful for me at some time in the near future, especially since my current version control only covers changes to the filesystem, omitting modifications to my sandbox's database contents -- which is relevant here.
In other words, some real equivalent for my imagined command doctrine:generate:rollback would be ideal. I'm assuming there's probably a way to do this type of thing.
Edit: TIL that the doctrine:generate:entity doesn't actually do anything to the database on its own. In many workflows, the doctrine:schema:update command does that after entities have been generated.
No, there is no Symfony or Doctrine command to do a rollback, but what doctrine:generate:entity really does is generating new php file with entity definition. So an actual rollback for doctrine:generate:entity is:
rm /path/to/your/entity.php
The answer is: No, there is no 'rollback' command, which removing all changes.
Do not forget that all changes in file system you can rollback via GIT (or other VCS).
I am running a set of migrations that denormalize one of my tables. I am running some code in one of the migrations that sets the ids in a new table based on the content of the current table.
For some reason, the id is not getting written correctly. To debug this, I would like to echo some of the variables out to the command line when I run the migration (in development). However, I have so far been unable to get those commands to work.
Yes, you can use all the usual ways (echo, var_dump, print_r). They will output normally to the command line in migrations.
If you suspect (as I did) that something about Laravel's migration system is silencing them, you are barking up the wrong tree.
I have 53 tables and a lot of them reference eachother with relationships. When i run:
php app/console doctrine:schema:create
I get the error maximum nesting level of 100 reached. Through research i found this is actually a security measure from xdebug to stop infinite loops. When i remove this limitation and run the command again the php cli stops working and im forced to close it.
Is there anyway to generate the schema in steps like build the database structure then go back and add the mappings and the indexes so that it doesnt fail?
Or is it possible that I am doing something else wrong?
MySQL does work and i can create schemas that have less tables / relationships using this same method.
UPDATE: doctrine:schema:create --dump-sql hangs as well. Both max nesting level and max execution time are set to unlimited. Still PHP CLI stops working:
Problem signature:
Problem Event Name: APPCRASH
Application Name: php.exe
Application Version: 5.3.26.0
Application Timestamp: 51af706d
Fault Module Name: ntdll.dll
Fault Module Version: 6.1.7601.17725
Fault Module Timestamp: 4ec49b8f
Exception Code: c00000fd
Exception Offset: 0002e8fb
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1033
Additional Information 1: 8983
Additional Information 2: 898375922a25a99ebc5721487ed92891
Additional Information 3: f337
Additional Information 4: f3378ae3d6023e7f336317eca89ba0b7
You have to increase the value of xdebug.max_nesting_level ( which defaults to 100 ) in your php.ini to circumvent the maximum nesting level of 100 reached error.
You'll most likely run into this issue multiple times for example during cache warmup - not only when trying to create the database schema. Therefore increase the value for all your symfony development - same goes for magento and zf ...
Check the max_execution_time setting aswell and maybe inspect using a profiler (xdebug/xhprof) if the command seems to hang. It might take some time to create the schema, bring some patience :)
There are no options for the doctrine:schema:create command to "split" the operation.
Try if doctrine:schema:create --dump-sql hangs aswell.
A really dirty workaround:
You could define new kernel environments (i.e. step1, step2), create different mappings (getting more and more detailed) or manually configure only a few of them in the first "steps"/environments, register/override them in config_stepx.yml and use something like
doctrine:schema:create --env=step1
doctrine:schema:update --env=step2
...
... but that would really be a mess.
from my experience the command should work even for large datasets. i have created schemas for applications with >100 tables without any problems.
The answer is my entities had a self referencing one to one relationship on the same key that was being used as the primary key. Thus creating an infinite loop during creation.
Not really sure why it was there in the first place some of these were generated by the doctrine database reverse engineering command.