I accidentally removed a folder (it might be db or lib folder), but immediately find out about it and put it back on same place it was (I am using RubyMine so I did cmd+z (on Mac)).
This caused so I got error: Migrations are pending. To resolve this issue, run rake db:migrate and I ran rake db:migrate and as I could see It ran all migrations files (from first migration file) and migrated all my tables as it was newly added and removed all my records.
Since I have version control, I rested the branch to previous branch but still have the same issue.
I have doubled checked all the folders and files and everything is where is needs to be (I think) but for some reason it needs to run all migration once again.
I am currently in Development ENV and don't know if it is going to run migration when deployed with capistrano gem to Production ENV and remove all my records in my Production ENV.
In my schema.rb my version is: ActiveRecord::Schema.define(version: 20161108160645) and 20161108160645 is the same number as my last migration file 20161108160645_add_name_avatar_to_comments.rb
What can I do to fix everything back to normal?
Rails version: 4.2.4
Ruby version: 2.2.1
db folder was removed and that causes all issues with pending migration.
Way to do is:
1) Remove project folder
2) With SourceTree clone the project
3) Run rake db:migrate to migrate all tables
Related
I have a django REST project and a PostgreSQL database deployed to DigitalOcean. When I develop locally, I have a separate dockerized REST server and a separate PostgreSQL database to test backend features without touching production data.
My question arises when I'm adding/modifying model fields that require me to make migrations using python [manage.py](https://manage.py) makemigrations and python [manage.py](https://manage.py) migrate command. Here is my current situation so far:
What I was supposed to do
IN LOCAL ENV, to create the migration files,
python manage.py makemigrations
python manage.py migrate
Now commit these newly created files, something like below.
git add app/migrations/...
git commit -m 'add migration files' app/migrations/...
IN PRODUCTION ENV, run only the below command.
python manage.py migrate
What I did so far
IN LOCAL ENV, created the migration files,
python manage.py makemigrations
python manage.py migrate
I committed & pushed the changes to production WITHOUT the created migration file
IN PRODUCTION ENV, ran BOTH commands.
python manage.py makemigrations
python manage.py migrate
The production server successfully added the isActive field to the database and is working fine, but I still have a 0011_user_isActive.py migration file in my local changes that hasn't been staged/committed/pushed to github repo.
And because I ran makemigrations command in production env, it probably created the same migration file that I haven't pushed from local env.
My questions are:
What happens if I push the local migration file to production? Wouldn't it create a conflict when I run migration command on digitalocean console in the future?
How should I fix this situation?
I am just scared I'm going to corrupt/conflict my production database as I'm very inexperienced in databases and have too much to risk at the moment. Would appreciate any tips on best practices when dealing with such situations!
As docs says:
The migration files for each app live in a “migrations” directory inside of that app, and are designed to be committed to, and distributed as part of, its codebase. You should be making them once on your development machine and then running the same migrations on your colleagues’ machines, your staging machines, and eventually your production machines.
So it's best practice is to push your migration files and make your local and production migration files sync.
And if you got conflict when pushing migraions files and pulling them, the makemigrations --merge command is for solving that.
Also docs says:
Because migrations are stored in version control, you’ll occasionally come across situations where you and another developer have both committed a migration to the same app at the same time, resulting in two migrations with the same number.
Don’t worry - the numbers are just there for developers’ reference, Django just cares that each migration has a different name. Migrations specify which other migrations they depend on - including earlier migrations in the same app - in the file, so it’s possible to detect when there’s two new migrations for the same app that aren’t ordered.
When this happens, Django will prompt you and give you some options. If it thinks it’s safe enough, it will offer to automatically linearize the two migrations for you. If not, you’ll have to go in and modify the migrations yourself - don’t worry, this isn’t difficult, and is explained more in Migration files below.
Also be aware that in case of updating existed data in production, you can use RunPython in migration file. Read about it here.
Conflicts occurring in migration files, Is it needed to commit the migration files or not? Is it needed to run makemigrations? (python,django 2.11)
Migrations are code. They must be in the repository. Don't generate migrations on server. On your developer machine only and don't forget to commit them. It's important to follow the rule: each commit that contains any model changes must contains appropriate migrations. Then when deploying you need to apply ones.
In other words, when someone pulls your code and runs manage.py makemigrations he or she doesn't produce any new migarions.
As of now, I'm using django 2. In dev we won't commit any migration files. We put the migration folder to gitignore, so that we won't commit.
When our code is pulled to production, they run makemigrations command, so that there won't be any migration issue.
With this production will have only one file for a model, where as in dev we may have multiple migration files same modal
I am not sure what you mean by production, but there is need to commit migrations. And you always need to run makemigrations before you migrate (if you are making changes to your model). And if there is any error, you might have to clearly state here.
I have 50 migrations files inside folder db/migrate, when I excute rake db:migrate always I get a schema file with version 0.
I don't unsderstand what happend.
I have tried delete all migrations file and execute rake db:schema:load but I can't do a new migration.
Thanks for your help
I had defined a environment var named VERSION. It blocked migration task
I'm using git to version control a Django 1.7 + Django CMS 3.0.6 project.
In the course of building various apps etc I'm ending up with a lot of migration files. The migration files are currently included in my git repo.
Thus far I have been trying to avoid including the virtual env files in my repo directly as it seems rather messy and redundant. Instead I have thus far been including a pip requirements file in the repo and using that to recreate the virtual env when needed.
However, I have recently discovered that choosing to include the migration files in the repo seems to require including all of the virtual env files in the repo as well. I say this because upon deploying my project to a production server and trying to run any of the db commands (syncdb, makemigrations or migrate) via python manage.py I get the error:
KeyError: u"Migration image_gallery.0001_initial dependencies reference nonexistent parent node (u'cms', u'0004_auto_20141108_1256')"
whereas such error does not occur on my local machine, even after deleting the database.
I tracked the source of this error down to the fact that the virtual env on my local machine has a reference to '0004_auto_20141108_1256' (inside the django-cms package - it appears some cms migration info is recorded directly inside the virtual env directory itself) while that of the production environment does not - as the production venv is create thorough a pip requirements file. Therefore, the two virtual envs do not exactly match, even though all third party libs are the same. Currently I am not including the venv in my git repo.
So as I see it I have two options:
1. include the virtual env in my git repo
2. drop the migration files from git
Which option is better and why - or is there a third even better way?
The downside to #1 is unnecessary bloat. The downside to option #2 is one loses the migration history, something one might potentially want to keep.
You never commit the virtual env, it defeats the purpose; you just add unnecessary content to git.
Instead, freeze the requirements and commit the file:
pip freeze > requirements.txt
Install the packages on the server:
pip install -r requirements.txt
The problem is in my django settings.py file:
MIGRATION_MODULES = {
'cms': 'cms.migrations_django',
'menus': 'menus.migrations_django',
'djangocms_file': 'djangocms_file.migrations_django',
...
}
I had to introduce the above to get django-cms 3.0.6 to work with django 1.7, a consequence of the fact that migrations in django 1.7 are no longer done with South, as django 1.7 now has it's own migration system, while cms 3.0.6. still expects migrations to be managed by South by default.
However, the effect of the above config is to store migrations in the above described paths which in my case pointed straight to the virtual env. Thus migration info was getting stored within the virtual env dir, leading to problems in deploying to production.
To fix this I modified my project directory structure to include a folder called "migrations":
myproject/manage.py
myproject/migrations/
myproject/myproject/
...
And modified the config to be:
MIGRATION_MODULES = {
'cms': 'migrations.cms.migrations_django',
'menus': 'migrations.menus.migrations_django',
'djangocms_file': 'migrations.djangocms_file.migrations_django',
...
}
This has the effect of now storing all migration files in the django project itself (and by extension the git repo). As migration info is no longer in the virtual env directory, there is no longer any reason to consider the rather unattractive possibility of including the virtual env in the repo.
Rails 4.1.1 production installation using Apache/Passenger configured to run rails app in a subdirectory "/myapp" instead of the root of the site.
All links in the app work fine, but in production references to assets in SCSS file, for example
background-image: image-url('logo.png');
get compiled to:
background-image: url("/assets/logo-<hash>.png");
instead of:
background-image: url("/myapp/assets/logo-<hash>.png");
I tried doing something like this when precompiling assets:
RAILS_ENV=production RAILS_RELATIVE_URL_ROOT=/myapp rake assets:precompile
but that had no effect.
I also tried setting config.relative_url_root in the config/environments/production.env file, with no luck.
The Rails guides say to set config.action_controller.relative_url_root, but that results in a missing method error.
I eventually gave up and embedded the image in the CSS file by using:
background-image: asset-data-url('logo.png');
which works, but only by avoiding the subdirectory problem altogether.
I know Rails makes you pay for not following conventions, but having an app in a subdirectory is not exactly outlandish.
I've seem all kinds of posts on this problem, but it's hard to get a straight answer. It seems to have been fixed a few times for earlier versions of Rails, but it's not clear if the fixes ever got into the standard Rails distribution.
In our case, we were able to make two changes, which seem to be working for us in Rails 4.1.6 :
1) In application.rb, assume there is a module named "MyAppName < Rails::Application". In here, we have
config.relative_url_root = "/myapp"
2) In config.ru:
map MyAppName::Application.config.relative_url_root || "/" do
run Rails.application
end
Without the config.ru update, things don't work properly.
After adding the jquery-ui-rails gem to another app deployed in a subdirectory, I had the same problem with the assets referred to by the built-in CSS for jQuery UI. I refused to modify the 3rd-party CSS files just to fix this problem, especially since Rails seems to be handling all paths (other than asset paths) correctly out of the box.
After pulling my hair out for some time, I don't know what prompted me to re-run the rake assets:precompile task exactly as given here. To my complete surprise, everything worked perfectly, both my own image URLs and jQuery UI's.
What made the difference? If I call the rake script from the app's bin folder as shown below, all the asset URLs are built incorrectly, without the subdirectory.
RAILS_ENV=production RAILS_RELATIVE_URL_ROOT=/myapp bin/rake assets:precompile
If instead I run rake via bundle exec, as follows, all the asset paths are generated correctly, including the subdirectory.
RAILS_RELATIVE_URL_ROOT=/myapp RAILS_ENV=production bundle exec rake assets:precompile
As to why this is happening, I can only conclude that running bin/rake does not load the right gems.