I'm still experiencing issues with the console commands in Doctrine 2.
During first set up of my project I could run the console commands to update the db from my annotated models without a problem e.g.
doctrine orm:schema-tool:update --force
Since then I've been diligently working away on the project and now need to run this again. However, now when the above runs nothing happens. No error message, no report on success - the command just completes silently.
I'm presuming that I've done something that's broken this but I've no way of knowing without some kind of error report so I'm stumped.
How can I work out what the problem is????
As long as you don't have any data fixtures in your DB you could try dropping it and recreating it again.
doctrine orm:schema-tool:drop --force --full-database
doctrine orm:schema-tool:create
Personally I manage the updates with the Doctrine migrations tool. I had some issues getting :update to work as expected when I was first trying it out.
Ok so I've got this working. Rather foolishly I'd added a class to the models directory that should have been elsewhere and removing this seems to permit the schema-tool to work. It would be nice if the tool gave some feedback though rather than just 'completing' silently, but ultimately just a daft oversight on my part.
Related
This happened to me a couple of months ago. It might have happened in the process of a composer update, but I'm far from sure on that one. I've even updated my project to Laravel 5.3 and it still I can not get make:migration to work through Artisan. No the project it updated to 5.4 and it still do not work.
I've checked out this thread and I have the exact same problem. The symptoms were exactly the same, however the OPs solutions did not work for me.
I get no error or result in the terminal when running make:migrate.
I can generate any other file through Artisan it seems.
I tried to create a new model and pass the -m along with it. Didn't work.
I've checked permissions (and even changed migration folder), but didn't
help.
If I create my own migration-file the rest of the process through artisan works fine (migrate, DB-manipulation etc).
I've tried with different terminals and computers.
Since project were upgraded and even reinstalled I fear it has
nothing to do with the deep kernal. However maybe some sort of conflict from the higher level.
And in the last phase of my quest I tried to figure out what user interacting elements that can possibly effect the make:migration. Nothing worked.
I searched the web without any solution, then I gave up on that project and started to make my own migration files. However I now got some new hope when I saw that other thread.
After some troubleshooting I finaly managed to figure out the problem.
I narrowed it down to have something to do with the config/app.php-file.
Seems I in this project had typed in:
'timezone' => 'UTC+2'
This made creation of migration-files come to a halt without error messages. And it effected only the creation of migration-files (at least what I noticed).
I changed it to 'UTC' and it worked liked a charm again.
Note: the 'UTC+2' worked in the application and I never saw any other indications of errors regarding the rest of the app.php-file, or in the application in general.
Solution: When I instead used the parameters from this site it all worked perfectly again.
I have a website in Symfony linked to a a MySQL database. The website is having some troubles, so I have to update the information in the database. The thing is, when I update on the database, it stays updated there but on the website it doesn't show any changes.
For example, a user is registered. I go to the database to change the email so I can register another account with the same email. The database is updated with the new email, but on the website it says that the old email is still in use.
I know that I am updating the right database, because when I register a new client on the website, it appears on the database. Any ideas on to why this might be happening?
Like Angel Iliikov mentions in the comments, it's very likely a caching issue. The following suggestions assumes you have access to the command line - which a typical Symfony user should. If you don't already have it, most hosting providers allow you to get SSH access.
Clear the following caches:
1. Symfony's cache
Symfony will store a lot of data in the cache files to prevent it from having to process requests from scratch. When Symfony apps go wonky, a very common fix is to clear this cache and retry. The standard way to clear this cache is with a console command run at your project's root directory:
$ app/console cache:clear
If you run into issues, David Soussan answer provides more information on this one.
2. Doctrine's cache
According to commenters on another question (formatted by me):
The doctrine cache is often stored in apc rather than in the file
system so removing the cache files would not help. The general app/console cache:clear is only for the symfony (app) cache. I don't think it clears the doctrine cache(s).
-caponica
Alternative PHP Cache (APC) is an optional component enabled in php.ini. It's possible Doctrine is caching information there as well if it happens to be enabled.
The accepted answer on the previously mentioned question provides an answer for clearing Doctrine's cache:
$ app/console doctrine:cache:clear-metadata
$ app/console doctrine:cache:clear-query
$ app/console doctrine:cache:clear-result
-amitchhajer
3. Your browser's cache
This is very unlikely to be causing any issues. But if you are doing something to send caching headers over HTTP - it's possible that the application would have properly updated the data, but your browser is displaying an old page.
Each browser has a different way of clearing cache. Google provides support for how to do it Chrome. and Mozilla provides support for how do it in Firefox.
If clearing the cache doesn't solve your problem, it's likely a problem with your application or workflow and will need debugging. A few things you can try:
Make sure you really updated the correct database. Confirm this
on two separate DB clients.
Create your own Symfony
command
where the only thing you do is query the database. If it returns the correct result, you should check that other components are using the same query. If not, check your config/parameters to ensure you're using the right database.
If your Symfony application is not showing the updated database record that is because it is using the cache which still contains the old data. This is often a problem with Symfony, refreshing the page just reloads from the cache. Try clearing the cache first. Now, very often cache:clear does not work from the command line, I've had it happen all the time and never really understood why. The answer is to just delete all the cache files, as per Fabien Potencier's tip: http://fabien.potencier.org/a-symfony-tip-clear-the-cache-without-the-command-line.html. That works and is my go-to solution for when eg; composer update did not clear the cache afterwards. In fact I got into the habit of just deleting the cache files on my dev machine before doing composer install or update.
Adam,
Use these commands to clear your cache:
# dev environment
$ app/console cache:clear
# production environment
$ app/console cache:clear --env=prod
I had problems using the mysql database supplied by my host server at first but then I installed the latest mysql database version available in softaculus inside my host server and then I was able to access mysql inside softaculus or directly by the url (www.mypage.com/mysql). Finally it works perfectly. You can try to do something similar.
Context : I have been asked today to add a new feature on a quite old project (something like Symfony 2.0). It consisted in adding a new attribute to an entity and add the corresponding field to the edition form. Child play : I have edited the code and it works well in dev environment (set directly in app.php)
Problem : When the environment set in app.php is prod, the entity is not persisted when the form is submitted, nor retrieved when the form is loaded.
Investigations : What I have checked so far in prod env :
The submitted form is correct
The controller manages to map the form and to hydrate the entity correctly
I have deleted the cache multiple times both manually and from command line
I have checked the SQL query after the form has been submitted, the query does not update my new field as expected
Supposition : The problem seems to apppear when the entity is flushed, it is like the new field was completely ignored.
Assumption : After having exposed my problem to more experienced symfony developers, the only suggestion was that there may be a PHP cache (not the symfony one) somewhere parasitizing my prodenv. This assumption is being tested (I could not restart apache myself) and I will be able to test it maybe tomorrow in the best scenario.
Still, I feel like the PHP cache assumption has 10% chance to be the good one. I can not share with you the whole project code, but I am asking you if you could post every idea you might have regarding this issue.
UPDATE : I have restarted Apache2. Problem is still persisting. It seems like Doctrine builds its cache on a former version of the project (It does not see any changes in the annotations for example) even though app/cache/ is empty. Any idea ?
I have deleted the cache multiple times both manually and from command
line
Can you clarify? Symfony's cache is not the same as doctrine's. Depending on your configuration doctrine could be using something like apc, reddis or something else to cache its own queries and result data. If you haven't yet, try to perform these commands:
app/console doctrine:cache:clear-metadata
app/console doctrine:cache:clear-query
app/console doctrine:cache:clear-result
If you're still out of luck, I'm more than 10% sure that an apache restart will do the trick.
If this worked, you should check your prods config yml and see if you find something like:
metadata_cache_driver : something
result_cache_driver : something
query_cache_driver : something
Full answer was to execute :
app/console doctrine:cache:clear-metadata --env=prod
The caching was caused by a memcache configuration only present in production environment.
I have 38 migration script that I wrote in Laravel 4.
I don't want to throw them away, but I also don't want to run them either. I just want to keep them as references.
If I place them in the migration folder in Laravel, it will run when I do
php artisan migrate and that will break some part of my database, as they have already been run.
I'm wondering if there is a way to mark them as already run, so Laravel will not trying to run them again.
I notice the migration table in my database - can I do something with it ?
What is the best way I should do to those 38 migrations ? Feel free to give me any suggestions.
Your question is a little confusing -- Laravel will only run each migration once. It keeps track of which migrations have run in the migrations table. The whole idea of migrations is a series of date sortable scripts that you can run at anytime start to finish and they rebuild your database, AND that you can add to without needing to rerun them all as they work (so your data is preserved)
If you're running
php artisan migrate
and Laravel's running a migration it has already run, something is very broken with your system.
(Speculation follows) It seems more likely the latest migration you're running may have halted half way though in a place MySQL couldn't rollback the changes, and Laravel's trying to rerun the latest one. Try a
php artisan migrate:rollback
Fix the error in the breaking migration, and you'll be all set.
I built a console app with Symfony Console component. It supposed to be run for 5 hours. But after running 2 hours i have a proc_open(): unable to create pipe Too many open files error in Symfony\Component\Console\Application.php on line 985.
I tried gc_collect_cycles in my loop, but got the same error.
Is this a Symfony Console component bug or i should not run an app for this long (but i have to)?
I had this same error with a Symfony web-app, and restarting PHP resolved it.
I appreciate that you can't do that in the midst of your command's 5-hour run, but maybe doing it immediately beforehand will get PHP in a clean enough state to give you the full 5 hours?
(Also, this post is the only one I found about my problem, so I wanted to add this here in case others have the same issue as me!)
This issue is related to:
https://bugs.php.net/bug.php?id=47396
Apparently you're working on a lot of resources in your app. It's not a Symfony Console bug, it's a PHP bug.
You can use another programming language or modify your program in order to open less files.