This question already has an answer here:
Hartl's rails tutorial completed works locally perfect. Heroku persists "We're sorry, but something went wrong."
(1 answer)
Closed 6 years ago.
I have a Ruby on Rails app and I want to deploy it on Heroku. Some errors appear and I think it is because the scaffolding order.
By that, I mean that a class named submissions is first created, but this class references another class named Users that is yet to be created.
This is the error that appears when doing rake db:migrate http://pastebin.com/R83a3rsN
And those are the migrate files and their filename
I guess you mean that:
http://pastebin.com/ig5nHjsj for 20160503205437_create_submissions
and
http://pastebin.com/q2jABiep for 20160428101834_create_users
You have a member in your db/migrate folder named...
20160424205437_create_submissions.db
Just rename it to
20160503205437_create_submissions.db
that will move it to the bottom of the list of migrations and it'll be executed last.
This doesn't seem like a scaffold error per se. Rather, it's an issue with migrations (which scaffolds happened to generate).
To repairs the issue, I'd probably just make a fresh migration which includes all columns your application needs at this point in time. Then edit the order of the create_table blocks to resolve your error.
Then you'd be able to delete the other migration files and run dB:create or reset.
This is an issue with cross-dependencies in your migration. In this case, the Submissions table is expecting that the Users table already exist in order to declare a foreign key to it.
Consider declaring the Users table above the Submissions table in your migration.
Related
I am new to Rails and I am facing the following problem. There were different tables in the existing project schema such as questionnaire, test, answers, questions, etc. But they did not have the columns of the creation date and the update date, and there were no models and views yet. So I decided to delete them and recreate them. Unfortunately I did it directly through the pgAdmin. Then I recreated each model with a scaffold generator. Everything was going fine until I got to the Questions model. For this model, I forgot to delete the table from the database, which I decided to do. But when I returned to the terminal and tried again to migrate the creation of the question table, I came across the same error message that the table already exists. Moreover, in the schema, I found that all tables manually removed from the database are still present.
What I tried:
I wrote migrations to drop tables. Migrations go through, tables disappear from the schema. Then I tried to write again table creation migrations, they are also started and tables are added to the schema, but they are not created in the database itself. But the application is still accessing the database, retrieving data, inserting it (into other tables that I have not touched on).
How can I return everything to the original? Migrations do not work in the project and I do not understand how to fix it. And I would not really like to dump the database, since it contains a lot of data.
Also in the project there are old migrations of test creation, test results, etc., which I deleted manually through the PG Admin. Should I delete them?
db/migrate
I found a bug. The problem was that the project turns out to be using docker (did not fully understand what it is). But as I understand it, for any update of the project, it must be reloaded through 4 commands in the terminal. Therefore, migrations did not go through the terminal. they had to be done by the docker himself. I expected to see the error logs right in the terminal, and they were issued by docker. I should have connected to the docker logs and read errors from there. There, he swore in plain text about the impossibility of migrating due to the lack of tables. I rolled back migrations to the state before the problem, removed migrations conflicting with the current state of the database and created new ones, according to the rails conventions. In the end, everything worked.
I have created an application with Ruby and Rails. The thing is that when I was develpoing it, I had some problems with the migrations, because I created them but with a wrong syntax. What happened is that I deleted some of the files because sold migrations that didn´t work had the same name than the new ones, but in the middle of that I accidentally deleted some of the migrations (obviously after running rails db:migrate) that the project uses actually. So for instance, i have the Service table, which is related to the Reservation table because Service has reservation_id, but i don´t have the migration file that says AddReservationIdToService.
So now I want to use Heroku for production. the thing is that O have to change to postgresql because Heroku doesn't support sqlite. So i have to run the de:migrate again to create the tables and relationships in the new DB, but I need the files that I explained that I deleted. The question is:
Can I create the migrations manually, so when i run db:migrate for postgres the full structure of the database is created without lacking relations?
You don't really need the migrations to recreate the existing DB -- in fact it's not a good idea to try for a couple of reasons (including the missing migration file problem you encountered). You can simply run:
bin/rails db:schema:load
to populate a new database from the existing schema. If for some reason you haven't got a db/schema.rb checked under version control you can run:
bin/rails db:schema:dump
against the sqlite version to re-create a fresh schema file from the database.
You can also keep your migrations list tidy by occasionally zapping really old migrations, since all the cumulative changes are captured in the schema file.
Yes, you might create another couple of migration files.
Certify you have now the tables you wish locally with your sqlite. Draw these table in a piece of paper (or where it be the best fr you), then check this official API documentation of Rails.
Delete all migrations made before and create another according to the tables you drew.
The workflow is gonna be like:
1) "I need to create a table called Reservation, where is it shown on the documentation?"
2) "I need a table called Service, where is it shown on the documentation?
3) "I need to add a column with a foreign key to service named reservaton_id, how does this documentation says it?
For all this steps above, create the correspondent migration file as you normally have done.
The main difference here is not to run the migration locally. Instead, push your new version app to your heroku remote branch and there you run the migration, like:
heroku run rails db:migrate
Remember to not run this same migration locally because you already have these tables locally.
The last two advise is:
1) If your migration doesn't go as you expect, don't delete the migration file. Instead, run rails db:rollback and try again.
2) Keep tracking your migration files on the same branch of your version control.
I've tried to solve this issue a few times now, but with no luck.
I recently switched my app over to Postgress from Sqlite3, but a now having issues generating models in Rails. The weird thing is that when I run a Rake db:migrate my terminal window states that the tables were created successfully. Although when I look into my Schema file the nearly created model doesn't show up. The model's attributes aren't accessible through rails console, which seems to let me know that the model doesn't yet exist in the database.
Am I wrong in my assumptions, or do you guys think there is something else going on here? I've googled this issue, but can't seem to find any relevant posts regarding this issue, so any help or suggestions is welcome.
Chances are the tables are created outside your search path.
Try \dn to list namespaces and then
\d myschema.*
To list all structures of tables within my schema. You can also
SET search_path = 'myschema';
\d
RESET search_path;
How do you go about changing column names and types in your rails app? Do you create a new migration to make the changes, or do you rollback, edit your migration file, and then migrate again?
What's the "proper" way to do this in Rails?
It sort of depends on when this happened in your development cycle, If you recently made the change and haven't pushed it out into a public repo, then you indeed might want to do the rollback thing and then edit the migration files and migrate again, just to keep things clean. But if it's a change to a migration that's a few migrations back then you should create a new migration that changes the rows and columns to the "new" old values.
Well, to undo a migration you typically want to roll it back:
bundle exec rake db:rollback
Where VERSION= can also be specified. If you wanted to change it to something entirely new, you would make a new migration. Typically you shouldn't be touching old migrations at all.
Rails gives you the choice of creating a migration and changing it a various of ways. So there is no "ruby developers" technique of choice.
However, every time you create a migration, a file is created, and it represents the history of your development. There are a lot of cases that a simpler file should be uselfull, like a code that other ruby beginners would have to look at and modify. On other cases may be necessary to an advanced developer understand changes and improvements made on the code, specially if it is a code running for a long time (some years maybe).
I made a new Rails 3 app today, added a simple migration, and for some reason, nothing happens when I do rake db:migrate. It simply pauses a few seconds, then returns to the command prompt, with no errors or anything. Schema.rb and the database stay empty.
Any ideas what could be going on? I've made many apps and never had this problem. Everything is a totally standard setup too.
There's a few reasons why your migrations won't run, but the most common is that the system is already under the impression that all the migrations you've defined have already run.
Each migration creates an entry in the schema_migrations table with the version column corresponding to the identifier number. If you want to force a migration to re-run you can usually back it out and retry it. For example, if you had 20100421175455_create_things.rb then you would re-run it using:
rake db:migrate:redo VERSION=20100421175455
A common situation is that your migration has failed to run in the first place, that it generated an exception for instance, and yet Rails still considers it complete. To forcibly re-run a migration, delete the corresponding record from the schema_migrations table and run rake db:migrate again.
One way to avoid this kind of problem in the future is to define your migrations with an automatic back-out procedure:
class CreateThings < ActiveRecord::Migration
def self.up
# ... (migration) ...
rescue
# If an exception occurs, back out of this migration, but ignore any
# exceptions generated there. Do the best you can.
self.down rescue nil
# Re-raise this exception for diagnostic purposes.
raise
end
end
If you have a mistake in your migration you will see the exception listed on the console. Since the migration has automatically been rolled back you should be able to run it again and again until you get it right.
I faced the same problem. I did a kind of a short hack that helped me. I am posting it just in case anyone wants a short and sweet solution. I agree with what Tadman is saying
"the system is already under the impression that all the migrations
you've defined have already run"
What I did was to change the name of the migrate file in the /app_folder/db/migrate folder. I think the numeric part in the name of the ruby migrate file is the time at which the file was created.
You can add say 1 , to the filename, every time you want to re-run the migrate. After changing the name drop/delete the table (I used mysql command line tool for deleting) and then run rake db:migrate and the migrations should be done.
Calling spring stop might solve your problems.
Well, I found out what was causing my problem. I'm using the slim_scrooge gem and commenting it out makes everything proceed normally. Don't know why though...
I faced similar problem today while migrating plugin for Redmine using
rake redmine:plugins:migrate RAILS_ENV=production NAME=plugin_name
where plugin_name is actually plugin name defined in init.rb of the plugin.
I struggled for 4 hours and finally figured out that my plugin directory name was not the same as the plugin name (note redmine_ prefix):
~/redmine/plugins/redmine_plugin_name
So, make sure your plugin is placed in folder named after plugin name. I believe it applies to other rails apps as well.