what does rake db:migrate do outside of looking at migration files? - ruby-on-rails-3

I'm trying to debug a problem I am having with migrating my db.
I had my application running without issue, and pushed it to heroku, and ran rake db:migrate and got the error
PG::Error: ERROR: relation "places" does not exist
LINE 4: WHERE a.attrelid = '"places"'::regclass
^
: SELECT a.attname, format_type(a.atttypid, a.atttypmod), d.adsrc, a.attnotnull
FROM pg_attribute a LEFT JOIN pg_attrdef d
ON a.attrelid = d.adrelid AND a.attnum = d.adnum
WHERE a.attrelid = '"places"'::regclass
AND a.attnum > 0 AND NOT a.attisdropped
ORDER BY a.attnum
I found it very strange that the migrations were fine locally, but not when migrating on the server. I found a few other people had had similar problems, but never found that anybody had a solution. No answers I found on StackOverflow had been accepted. After a few hours of trying different things, I thought I'd try to create a new heroku app from scratch and push my app to it (that worked for somebody else), basically starting fresh.
When I did that, I got the same error, but now on the wineries.
Weird, on the recommendation of Heroku, I tried creating a new db locally, and running my migrations.
Now locally, I get the same error, but on the table admin_users.
I'm pretty sure there is nothing wrong with the actual migration files, as each time I run the migration, I get a different table and therefore in some ways a different migration which is being affected.
I've tried removing a few gems, but still et the same error.
Does rake:db look outside any files other than the migration files? Could this be a relationship issue?
Any other suggestions on how to resolve this?

Are you accessing/using any models in your migrations to do any data updates? Are you using any models in anything in config/initializers? rake db:migrate loads the rails environment so if you try and access a model that doesn't exist yet it will spit this error out...

Related

Rails 3.2 structure.sql changes not generating

On this particular project we're on Rails 3.2 and we use SQL for our schema format, which generates structure.sql. So in application.rb:
config.active_record.schema_format = :sql
This has never been an issue in the past. Whenever migrations are run, Rails would automatically update structure.sql accordingly.
However, recently this stopped happening. No matter what changes in the db structure, structure.sql will not update. Unable to get to the root of the issue I've recently been updating structure.sql manually; which is a horrible, error-laden ritual at best.
Any thoughts appreciated.
Update
After reading "pg_dump: invalid option -- i" when migrating it seems like it may be related to a bug in Rails 3.2.x conflicting with postgresql 9.5+. So I'm not sure if there is a solution outside of upgrading Rails which isn't currently a viable option.
Try running:
rake db:structure:dump

Rails friendly_id: undefined method `slug` on production

I'm trying to introduce dynamic_sitemaps over resources with friendly_id. The issue is the production rails (rake / rails c) doesn't see the slug method. I've try to specify it by force by specifying an attr_accessible :slug, but it doesn't help either.
$ rake sitemap:generate
Generating sitemap...
rake aborted!
undefined method `slug' for #<Article:0xa9e4d14>
The funny thing it works smoothly on the local environment, and it should not be so much different with the capistrano/rvm deployment.
The column exists in the DB and is used by the rails app itself (which works fine too).
Added: it should be tied to either the environment or the specific gem version issue, but I'm not sure which one is the trouble, and how to debug it. The same pair works good for a different project with a pretty similar libraries bundle.
As the capistrano always do the dirty work, I forgot about the RAILS_ENV environment variable - so the console and cron job tried to operate against the dev DB and obviously failed.

how can i remove the file from heroku master

heroku rake db:migrate
== AddFilesizeToPapclip: migrating ===========================================
-- add_column(:papclips, :files_file_size, :string)
rake aborted!
An error has occurred, this and all later migrations canceled:
PG::DuplicateColumn: ERROR: column "files_file_size" of relation "papclips" already exists
then how can i rectify this error?
Advance Thanks.
The AddFilesizeToPapclip migration tries to add a database column files_file_size that already exists in table papclips.
If you want to manually remove this column, try this:
Open a Rails console on your Heroku app: heroku run console
Then run this code: ActiveRecord::Migration.remove_column :papclips, :files_file_size

Unable to access config.handlebars in production mode

I've got an existing rails app, and I've added an ember front-end. I'm having trouble deploying the new version (which includes Ember for the first time) to Heroku.
The problem is that I'm unable to run rake tasks in production mode.
I discovered this when I tried to rake db:migrate on heroku. I got the following error:
rake aborted!
undefined method `handlebars' for #<Rails::Application::Configuration:0x00000004f0de90>/app/.bundle/gems/ruby/1.9.1/gems/railties-3.2.13/lib/rails/railtie/configuration.rb:85:in `method_missing'
/app/config/application.rb:60:in `<class:Application>'
I get the same error if I try to run any tasks locally in production mode, e.g.:
RAILS_ENV=production rake -T
the offending line, from config/application.rb:
config.handlebars.templates_root = 'ember/templates'
for various reasons, I had to move the ember templates down one file level. and it needs to stay there. everything works fine in development mode.
Any idea how I can fix this?
tried upgrading the ember-rails gem. this didn't help. (I'm using 0.12.0)
trick was to move ember-rails gem out of assets group

After upgrading Postgres and Rails I cannot get my migrations back on track

I had a working setup using Rails 3.1 and Postgres 9.0 and just upgraded Rails to 3.2.1 and Postgres 9.1.2.
Upgrading postgres meant migrating the data as the 2 versions datastores are incompatible. I didn't care much to migrate the data in my local db's as they are all used for development purposes anyway. So I'm trying to recreate my databases using Rails migrations (or w/ schema). However no matter what I try I cannot get the migrations to run.
Using either
rake db:migrate
or
rake db:reset
Running this on with my Postgres 9.1.2 setup gives me:
spif: > rake db:migrate
rake aborted!
PG::Error: ERROR: relation "users" does not exist
LINE 4: WHERE a.attrelid = '"users"'::regclass
^
: SELECT a.attname, format_type(a.atttypid, a.atttypmod), d.adsrc, a.attnotnull
FROM pg_attribute a LEFT JOIN pg_attrdef d
ON a.attrelid = d.adrelid AND a.attnum = d.adnum
WHERE a.attrelid = '"users"'::regclass
AND a.attnum > 0 AND NOT a.attisdropped
ORDER BY a.attnum
Tasks: TOP => db:migrate => environment
(See full trace by running task with --trace)
At first I though it might be that the pg gem doesn't support Rails 3.2.1 yet so tried with sqlite3 as well but that gives me the same users not found:
spif: > rake db:reset
rake aborted!
Could not find table 'users'
So it looks like Rails expects a users table somewhere.
I have no clue how to find out what code is actually calling this. When I run the migration commands with --trace it show's that is ActiveRecord internals doing it. Can this be a bug in ActiveRecord 3.2.1 (how would I go about finding that out?).
I can connect to the pg db's fine using psql and my user setup in config/database.yml. Does rails expect some postgres tables that it can query about users?
I have completely removed my db/migrate directory and the db/schema.rb in order to make sure there is not some strange internal dependency there but also to no avail.
I'm sure I'm missing some simple concept - I haven't often tried to reset my db from scratch so I hope there is a simple explanation.
Thanks, help very much appreciated.
I solved this by manually creating the users table and each other table I had in this project. Then ran the migrations again and everything is setup fine. There were only a few tables so it wasn't too cumbersome but not the "fix" I was trying to find.
Looks like 'mu is too short' was right that this is related to ActiveAdmin and the way it loads itself when loading the environment during any db operation (or rails server/console too for that matter).
Thanks for the pointers mu.
DO you use any model load in initializers?
I had the same problem and i was loading the model in an initializer, so the error comes, because the table doesn't exist before doing the migration and i was trying to load something that ever doesn't exist!