I have a rails program that is accessing a legacy database with UPPERCASE table columns.
I want to be able to type user.firstname rather than user.FIRSTNAME
How do I make ActiveRecord retrieve the lowercase version of these column names to allow me to use lowercase attributes in the model?
It might be easier to change the column names with migrations. Otherwise you will have to change the gems that you are using and then pack them in vendor/gems to keep as they degrade.
script/generate migration down_case_table_names_and_columns
write the migration
rake db:migrate
For each table:
rename_table :OLD_NAME, :new_name
For each column:
rename_column :COLUMN_NAME, :column_name
problems
You might not have to change the name of the tables, fyi - you might get an error about changing the table names. I have never changed a table name so I don't know if this will work. In therms of changing column names there will be no problem.
This is probably the best way to deal with this if changing column names isn't feasible: https://github.com/reidmix/legacy_mappings
Related
I developed a Ruby on Rails 5 application and deployed it to a production environment, after running rake db:migrate I noticed that I wasn't using foreign_key: true and neither index: true for my general relations between tables. Question is: Will this affect database performance and should I generate new migrations just to add indexes and foreign keys references to my columns? Thanks in advance.
From Ruby on Rails guide:
2.2 Schema Conventions
Active Record uses naming conventions for the columns in database tables, depending on the purpose of these columns.
Foreign keys - These fields should be named following the pattern
singularized_table_name_id (e.g., item_id, order_id). These are the
fields that Active Record will look for when you create associations
between your models.
Primary keys - By default, Active Record will use an integer column
named id as the table's primary key. When using Active Record
Migrations to create your tables, this column will be automatically
created.
You must know more about ActiveRecord Look here how it works here
I suggest you to read about belongs_to and has_many relations
Depends on what you are going to do, if you have relations where the foreign key is needed, you will need to create those migrations, otherwise you wont be able to access them.
When it comes to db performance it doesnt matter really
I use this command ：
rails g migration CreateJoinTableUserPloy user ploy
And i check the Migration file：
create_join_table :Users, :Posts do |t|
#t.index [:user_id, :ploy_id]
#t.index [:ploy_id, :user_id]
end
There are 2 index is be commented by defualt.
Then i run this command:
rake db:migrate
Then i check my database structure
And i not seen primary key, Does it mean that join tabel no need add index and primary key in database structure?
Consistent with http://meta.serverfault.com/a/1931, I'm going to respond to this as an answer, even though some of the information is in the comment thread.
There is no primary key in a Rails-generated join table (i.e. as created by create_join_table, which is used by migrations with JoinTable in their name) and Rails has no inherent requirement for one. That's because most pure join tables are only accessed by the id's of the joined tables, in which case primary_key is unnecessary. You can, of course, add and designate a primary key column if you wish.
Rails does not support multiple column primary_keys, although there are multiple gems that provide that support, such as https://github.com/composite-primary-keys/composite_primary_keys.
Further, there is no fundamental need to create an index. You can create one if you wish, and it will speed up access to records at the cost of some additional time spent on record creation and update. See https://stackoverflow.com/a/3658980/1008891 for more discussion of this.
it is possible to tell rails to keep id columns at the top of the schema and timepstamps at the bottom, when adding some fields to a table through a migration?
What I want is to have always this fields in the same position when playing with rails on the console, I know it's possible to reorder them in schema.rb and reload it but I'm looking for a cleaner approach suitable for production environments too.
thank you
You can something like this (probably currently in Mysql only) from Rails 2.3.6+:
add_column :table_name, :column_name, :column_type, after: :other_column_name
or
change_table :the_table do |t|
t.column_type :column_name, after: :other_column_name
end
Sources:
- In a Rails Migration (MySQL), can you specify what position a new column should be?
- https://rails.lighthouseapp.com/projects/8994/tickets/3286-patch-add-support-for-mysql-column-positioning-to-migrations
You may be interested in the fix-db-schema-conflicts gem which automatically sorts columns alphabetically while generating the db/schema.rb file.
Timestamps would not necessarily be last in the list, but the schema will not rely on the order in which columns were added (by migrations).
If I've got a column in a database, I want to write a migration that generates another column that contains the md5 hash of the first column. The encryption I can do, but roughly what should the migration look like, structurally? Do I just do a for-each?
I would do it like this with a sql query because this is about the whole table and iteration would slow it down useless.
add_column :table_name, :password_md5, :string
ActiveRecord::Base.connection().execute("UPDATE table_name SET password_md5=MD5(password_plain)")
To add the phone column to the tickets table, I can write:
ruby script/generate migration AddPhoneToTickets phone:string
There seems to be a redundancy here. But is it necessary?
Aren't we repeating ourselves by being required to specify "phone" both in the name of the migration (AddPhoneToTickets) as well as in the column definition (phone:string)?
You're not required to put Phone in the migration name. For example, if you were adding a bunch of contact fields, you could just as easily call it AddContactFieldsToTickets and specify all the fields. It's not specific enough to use the name of the migration for anything but the table name, really.