I've got a problem when I run
php artisan migrate
Only four of my sixteen migrations get run for some reason. No errors are spit out, and I checked, all three of the databases are there. Can anybody point me in the right direction?
Results of -vvv is not different than no -v or -v.
Related
I have been happily unit testing in Laravel 9 for the last few days and am gradually getting the hang of how to write tests for various circumstances. I ran many tests and was learning a lot when suddenly, for no obvious reason, the php artisan test command stopped working properly. Starting at about 11am today, the very first test in the very first test case executes successfully and then the whole thing just stalls: no other tests are attempted. There are no error messages and waiting prolonged periods doesn't result in the tests restarting on their own.
I've tried doing a CTRL-C to break out of the test and then started again. Same result. I've tried closing the terminal window, opening another and running php artisan test again. I've tried using a different terminal window outside of VS Code altogether. Same result. I've tried closing and re-opening VS Code. Same result. I've even rebooted the computer (I'm running Windows 10) but am getting exactly the same result. I just can't get beyond the first test in the first test case.
I can't think of anything else to try. The second test case has been run successfully many times so I can't believe it is the problem. Can anyone suggest what the problem might be and how I can get past it?
I'm using PHPUnit 9.x.
UPDATE
As per Matias' suggestion, I ran php artisan test -vvv on my test suite. (I also renamed all of the files in the Unit Test directory so that they wouldn't run, except for the two ExampleTest test cases that were generated by Laravel, one for feature testing and one for unit testing.) The very long stacktrace pointed to an inability of the tests to connect to my local MySQL database. That made sense because I hadn't restarted XAMPP after the reboot. (Then again, I didn't see the urgency because none of the code I was testing used the database; they dealt with strings, arrays and collections.) I restarted XAMPP, including Apache and MySQL. Now, all tests the ExampleTest test cases completed. I renamed my Helper2Txxx.php to Helper2Test.php and assumed it would run smoothly now. Unfortunately, that didn't happen. Helper2Text.php don't run at all: the testing stopped as soon as the ExampleTest had finished.
I commented out all but the most trivial test in Helper2Test and it ran successfully. I uncommented a few tests at a time until I found the one that made all of the test cycle stop and that (unsurprisingly) turned out to be the last one I had written. Further investigation revealed that a small function I'd written to help with the testing was running into a memory error:
Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 264257536 bytes) in C:\Laravel\laragigs\tests\Unit\Helper2Test.php on line 154
It looks very much like I have to fix up my small function but I won't be able to do that to untilmorrow sometime. My working theory is that this memory error is the big problem that somehow breaks artisan test; somehow this kept the successful tests earlier in Helper2Test from displaying so that I had no idea where/why the test command was failing.
I'll update here as I learn more. I think I will be able to fix this problem myself but I'll leave the problem open in case I turn out to be wrong.
UPDATE 2
Everything is working now. I reworked my small function to accomplish the same thing via explode() instead of strtok() and it now works perfectly with no memory issues.
Thank you, Matias, for reminding me that I can get diagnostics by using the -vvv subcommand! That was the critical step in figuring out what was wrong.
I had an issues with the last migration. I needed to rerun it, but it told me "nothing to migrate".
I have done some research and found that migrate fresh will reset the migrates, so I can run it again.
But it seems that I missunderstood what it does. It recreated the whole db and deleted everything...
What now? It was a dev DB, but recreating everything will take hours now.
Is there a way to reverse it?
I'm new to Heroku and I've noticed that their page provides a tutorial on NodeJS where they go step by step on how to integrate a project or start a new project on their platform. Through the last step there's a section for databases, using postgres as an example, which happens to be the database type I'm looking to integrate in my project as well. However, after following through with the tutorial, I noticed that when executing heroku pg:psql, the Git Bash (what I used) keeps showing Connecting to [...] (the name of the database) and nothing else happens, effectively not allowing me to create rows and whatnot in the database so I can see them as part of the application. Have I gone wrong somewhere, or am I just missing something?
I have tried multiple ways to make sure it's connecting to the right database, I have even made a new database, however nothing works and the process keeps going endlessly. I've let it run for more than a day and still goes nowhere.
According to this source, https://devcenter.heroku.com/articles/getting-started-with-nodejs#provision-a-database, I should be connected to it with that bit of code there, however the only thing that I'm shown is --> Connecting to postgresql-animate-97685 .
I just had the same mistake and could not find a solution. I spent a lot of time to understand what needs to be done for this.
As a result, as I decided:
I originally used the console from Git Bash. Instead, I tried using the standard console from Windows - cmd. And it all worked out as per the instructions from Heroku.
By the way, this is not the first time that Git Bash fails me.
Hope that helped.
I have several customs commands in my application i have make a typo in call , for showing alls to you.
If i run only day:All i have this result.
Its great my code works good and i have the result that i want but it seem to run all the other customs command that i have and i don't want that.
I want to run only the day:All not varDay or graph.
The proof of this behaviour is , if i add a dd('foo') in my graph:All command, and i run again i have this.
Anyone know a way to run only the command that i want and not make Artisan run alls?
Any help is welcome.
After creating a new Laravel project with laravel new, there are a couple of migration files in the database > migrations folder:
2014_10_12_000000_create_users_table.php
2014_10_12_100000_create_password_resets_table.php
These seem to be examples of typically useful migrations and are probably a good place to start if you need a system that requires something similar. However I'd like to delete them so they don't clash with something in a new project I'm building.
I was hoping I would be just able to delete the files, as I've not run php artisan migrate yet, but when I try my IDE says:
Why are these files already tied into the system, and how can I safely remove them? Is there some documentation on the Laravel site that I've not been able to find about this?
I guess I could ignore the warning and try running composer dump-autoload -o, but is this really OK?
Why are these files already tied into the system
to map all project classes
how can I safely remove them?
Ignore IDE and delete them then run composer dump-autoload and will remap project classes
Is there some documentation on the Laravel site that I've not been
able to find about this?
i don't see any thing about this in laravel documentation site
Ignore the warnings and delete them. The migrations that come out of the box are to help you get started with basic auth. You don't necessarily need them. Run composer dump-autoload when you're done.