We have always had some issues with rails schema file. It got worse after upgraded from rails 3 to rails 4.2. So everytime someone runs "db: migrate" on the local machine, it adds, removes or edit stuff in the schema file. Nothing got affected in the database though.
When we were on Rails3, we got changes like string limit: 255 changes to 100, columns removed and added back in a different row. In Rails 4, apart from the pre-existing ones, we got all the timestamp (created_at, updated_at) added with null: false. We don't set up the default for timestamp in migration files. Also, the index names are changed to those rails generated ones, but we do specify the index names and they are sitting in the database without any issue.
Now it gets really annoying as it causes conflicts on and making noise. Any suggestion to fix this?
User Rails 4.2.10, Ruby 2.5.3, mysql version 5.7.22 by Homebrew.
Related
I'm a total newbie with Ruby, Rails, Rake, MySQL (on Ubuntu/bash/command line) and devise (warden 1.2.3, devise 3.0.4). I must continue with what have been done so far : the Rails 4 project is working and linked to a MySQL database (full, populated with users and data). I'm able to change controllers and views.
I must add devise to the project. I'm reading this : https://github.com/plataformatec/devise . My class name is User. So I did rails generate devise User.
When I do rake db:migrate I have this error : Mysql2::Error: Table 'users' already exists: ... of course, since I already have a users table in my project.
Whatever I read ( Devise with Rails 4 ), it's always about create the User model, never how to plug devise on a pre-existing User model.
What document should I read ? Which file I must edit to tell devise "this is my user model and table:" ?
If Ruby/Rails is brand new for you, and you're lost.. (like I was...).
Look for the migration file (migration-name.rb) in "/yourproject/db/migrate/". This file was generated by rails generate devise User (User can by any Model, like UserAdmin or Client ...). This file tells you the modifications Devise will do to the database (what it needs).
Look at this file carefully and make sure that your database match the requirements. If you run rake db:migrate rake will attempt to modify your database. Maybe this is your error (attempt to create a table User, since your table User is already created).
Modify your migration file. You may also change your database manually and delete the migration file (if you don't care to keep track of your migrations); in this last case, of course, you don't have to run the rake command.
Follow the Devise getting-started guide, and intelligently apply the manual steps to your current project where necessary.
https://github.com/plataformatec/devise#getting-started
Recently we moved our application from rails 2.3.11 to rails 3.0.7, after everything was done we saw a weird issue. Whenever we generate a migration, the number is auto incrementing where as we needed migration number in UTC timestamp. Since there are 5 members in our team, its causing very big problem.
Kindly help me to resolve this issue.
Set config.active_record.timestamped_migrations = true in your config/application.rb
I'm migrating my application from Rails 3.0.12 to 3.2. I use the active_record_store to work with my session variables, owing the size limits on the default cookie store. On the new version of Rails, however, the session variable is not getting set.
I can see that the cookie session_id is being set with a value, but I can look at the contents of the database and see no values being inserted when a session variable is supposed to be populated.
However, if I switch back to cookie store, it works fine. Is there anything I can check to find out what's going on?
I'm afraid the problem solved itself, perhaps in a Gem update that I performed in preparing to respond to the comments on this question. I had the Rails 3.2 version of my app on a separate Git branch, so I brought it back and merged it with my current development version.... and it all "just works".
I can't help but think this was a transient issue with either an older version of my code or a gem, but it's solved now, so I'll close this question.
This is in development mode. ActiveRecord::StatementInvalid. This is an example: I have a model called DisplayAds. Now activerecord wants to query the table as display_adses instead of display_ads. I have another model called Media. Activerecord use to query the table medias. Now it wants to query a table called medium.
I know that DisplayAds is not the proper naming convention but it was working until now.
I realize I can fix this by putting set_table_name in the model.
I have not upgraded rails and everything has been working fine for months.
I have a live production version of this site and it is not experiencing this problem.
I do git status and I do not see any config files as being modified.
What could I have done to start this happening? How can I stop it?
Have you recently upgraded from 2.3.5/8 to 3.0.x? I had the same problem (same thing with medias).
You'll want to add irregular Inflections in your config/initializers/inflections.rb file
ActiveSupport::Inflector.inflections do |inflect|
inflect.irregular 'media', 'medias'
inflect.irregular 'display_ad', 'display_ads'
...
end
My app is in beta, and I've been doing limited testing of a feature that involves a new model. After a fair amount of testing I had to make a structural change that makes the old data non-functional.
What I need to do is just drop and recreate one table. I know that I could do this in a migration, but that seems like such a hack. In a local dev copy I would just use db:reset, but in the beta app I don't want to lose data in any tables except this one.
Is this a simple way to instruct a production app to drop and recreate a single table. In my case, I'm deploying with Heroku, in case that affects how you would solve this issue.
To empty a table on Heroku without changing the schema, in your application's directory:
$ heroku run console
Ruby console for myap.heroku.com
>> ModelName.delete_all
>> exit
I know that I could do this in a migration, but that seems like such a hack.
It's not a hack. It's precisely what migrations are designed to do.
You need to rerun the migration for that table to make structural changes. I haven't used ActiveRecord before, but I'd also delete the data in the table using ModelName.delete_all from heroku console.
heroku run console
irb(main):001:0> ModelName.delete_all
And you are done.