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?
Related
My question is when I change anything in the Example.vue, User.vue or any of my Vue components and refresh my browser it doesn't get the updates at all, the old values still remain. Even if I delete the entire code in any of my components it's still there. I clear my browser cache, restart the computer, run dev, npm run watch, ran dump-autoload, Php artisan clear cache. I am using laravel 5.8. I am running or of ideas. Any ideas.
Thanks
Do you have supervisor running on your pc? If you do, run
supervisorctl restart all
read more here
and here
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.
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.
I have created database project in visual studio 2013 from existing database. Then I have done lot of changes in database project like modify stored procedures, post deployment script, table structure, etc . Now database project is ready to deploy. But I am worry if any script fails then How I can retain the original state though it build properly.
Please suggest that if any query fails then I want ROLLBACK the all changes that I have made in database project.
Firstly you need to trust your tools and either believe they will work or find other tools.
While you are building the trust I would add a create backup to the pre-deployment script or run a backup before you deploy then if anything goes wrong you can restore and figure out what went wrong.
As David said to roll-back, you would get the previously deployed dacpac and generate a new deployment script from that but fixing forward is almost always the correct thing to do rather than rolling back to a previous version.
ed
Have you been checking your changes into version control? If so, all you need to do is to revert back to the last known good version.
Or... simply work out why it's failing now and fix the root cause?
I used Db projects some time ago and as far as I remember the deploy script was wrapped in a transaction. It is possible to generate sql script without executing it. That setting was somewhere in DB project settings. You can take a look inside that script and make sure that it'll rollback on error.
Doing a backup would still be a recommended practice especially when you deploy to production.
when working on important scripts I developed a habit of always starting a transaction and commenting out the commit.
If you accidentally run it, it won't take effect. The commented out commit would only come out when the thing was done.
While this answer indicates that you CAN revert in source control (Assuming SSDT at this point) it would be nice to get a pointer to the exact process to do this. On a file by file basis the history works the same but how to revert the entire database at once isn't immediately obvious.
Being newer to Ruby on Rails and while I have a fair understanding of certain areas, I am still learning. The one area I have difficulty is migrations/databases and I fear I may have had a terrible mistake.
I am currently working on building a blog and recently added a comments section. My next project was to have friendly URLs (using the friendly_id gem) and when I needed to create a new column for slugs, it seemed to already exist (from trying at a previous time I suppose).
Anyway, I tried to reset to an older commit but I know now (unless I am mistaken) that it has no affect on migrations? After some research I tried to rollback my database to undo whatever happened with the slugs. Ultimately, I went too far back that the only database I had was for my blog posts (and nothing for the users and comments).
I have since done a rake db:migrate and everything has been generated again but the content (via the localhost) was removed. I don't mind that because the content I have on my localhost does not have everything my live site does (http://www.joedayvie.com), granted its not much there either.
Anyway, I am really lost at this point and concerned. If I git push heroku master in the console will my content be removed or will this happen when I update the migrations onto heroku? Is there anything I can do to revert prior to this whole mess happening?
I apologize for seeming quite confused (but I am 100% self taught and lost). I greatly appreciate any information anyone may be able to provide me.
Thank you so much for reading!
Joe
PS: Of course if it's possible that this may not affect my website at all, please let me know. I just want to know more information before going further - Thank you! =)
You need to read about backups on Heroku
Then - you need to create a backup of your production system on heroku and prove to yourself that you can load it, by doing so on your local system.
When you have your local system looking like your production system again, you will know that you know how to recover even if the mess does happen again.