I have designed the following migration and wanted to check with the community is that is meeting the best practices of rails migration. I am running a postgres db.
I am trying to achieve a db structure where the various status attached to a user is stored in a separate table. for instance, its marital status.
let me know if that sounds like a reasonably efficient table design. and what I could improve.
class CreatePrequalifications < ActiveRecord::Migration[5.2]
def change
create_table :prequalifications do |t|
t.string :attachment
t.text :description
t.integer :marital_status
t.integer :professional_status
t.integer :collateral_status
t.integer :income_direct
t.integer :income_support
t.integer :income_scolarship
t.integer :income_other
t.boolean :blacklist
t.references :user, foreign_key: true
t.timestamps
end
end
create_table :marital_status do |t|
t.string :single
t.string :married
t.string :other
t.string :divorced
t.string :with_dependants
t.references :user, foreign_key: true
t.references :prequalifications, foreign_key: true
end
create_table :professional_status do |t|
t.string :self_employed
t.string :employed
t.string :student
t.string :other
t.text :description
t.datetime :contract_created_at
t.datetime :contract_terminated_at
t.references :user, foreign_key: true
t.references :prequalifications, foreign_key: true
end
create_table :collateral_status do |t|
t.string :collateral_name
t.string :collateral_income
t.boolean :visale_collateral
t.boolean :student_collateral
t.boolean :bank_collateral
t.references :user, foreign_key: true
t.references :prequalifications, foreign_key: true
end
end
In this case, best practices would dictate:
Break each create_table into its own migration.
Your table names should be pluralized, e.g. marital_statuses.
Time stamps are a good idea.
Consider adding indexes to fields that will be queried regularly, e.g. model names, user emails, or foreign keys.
Check out the rails guide on migrations for information about best practice: https://edgeguides.rubyonrails.org/active_record_migrations.html
Let's start with:
Is it a single migration? If so, I would start with splitting it into several migrations (one for each table).
Add timestamps for each table (t.timestamps null: false). You will thank me later ;)
For statuses tables (martial_status, professional_status) create simpler tables with just name and references (no need to create column for each value). Also, you probably do not need the table for marital status, because you can use classy_enum instead.
In prequalifications you have integer columns for relations (maritial_status, professional_status). Don't do that, use references.
For boolean columns, define default values.
Related
I have a User model with uuid for id column.
Ahoy gem creates visits as expected but the user_id is wrong.
Any ideas?
ok. Got that. Ahoy gem doesn't work with user_id as UUID. It takes the first digits from uuid and stores that in user_id for Ahoy::Visit which could look like random value.
The solution is to change the user_id type to uuid.
This migration would do the trick:
class ChangeAhoyVisits < ActiveRecord::Migration[5.2]
def change
Ahoy::Visit.destroy_all
remove_column :ahoy_visits, :user_id, :bigint
add_column :ahoy_visits, :user_id, :uuid, foreign_key: true, null: true
add_index :ahoy_visits, :user_id
end
end
Probably need to add the same type: :uuid to the user_id column in the ahoy_events table as well. After a few rake db:rollback's I ended up modifying the original migration file that is created by rails generate ahoy:install to look like this before I ran the migration:
def change
create_table :ahoy_visits do |t|
t.string :visit_token
t.string :visitor_token
# the rest are recommended but optional
# simply remove any you don't want
# user
t.references :user, type: :uuid, foreign_key: true, index: true
# standard
t.string :ip
t.text :user_agent
t.text :referrer
t.string :referring_domain
t.text :landing_page
# technology
t.string :browser
t.string :os
t.string :device_type
# location
t.string :country
t.string :region
t.string :city
t.float :latitude
t.float :longitude
# utm parameters
t.string :utm_source
t.string :utm_medium
t.string :utm_term
t.string :utm_content
t.string :utm_campaign
# native apps
t.string :app_version
t.string :os_version
t.string :platform
t.datetime :started_at
end
add_index :ahoy_visits, :visit_token, unique: true
create_table :ahoy_events do |t|
t.references :visit
t.references :user, type: :uuid, foreign_key: true, index: true
t.string :name
t.jsonb :properties
t.datetime :time
end
add_index :ahoy_events, [:name, :time]
add_index :ahoy_events, :properties, using: :gin, opclass: :jsonb_path_ops
end
And after running this slightly modified migration rather than original everything seemed to populate properly on an 'ahoy.track' in the db.
so i have 2 models:
create_table "holders", :force => true do |t|
t.string "faceid"
t.integer "badges_id"
t.datetime "created_at", :null => false
t.datetime "updated_at", :null => false
end
add_index "holders", ["badges_id"], :name => "index_holders_on_badges_id"
create_table "badges", :force => true do |t|
t.string "name"
t.text "description"
t.datetime "created_at", :null => false
t.datetime "updated_at", :null => false
end
i need 2 things:
to get all the badges of a certain faceid holder
to get all the holders of a certain badge.
i know its really noobs question but until now i didnt work with references so i dont really understood from the literature how to make the connection.
You actually need a many to many association on your holder and badge models. So you have to options either use has many :through or use has_and_belongs_to_many. The difference between the two can be found here. I am taking the example for has_many :through.
You need to create three models.
class Holder < ActiveRecord:Base
has_many :badges_holders
has_many :badges, :through => :badges_holders
end
class Badge < ActiveRecord:Base
has_many :badges_holders
has_many :holders, :through => :badges_holders
end
class BadgesHolder < ActiveRecord:Base
belongs :badge
belongs :holder
end
And your migration files needs to be:
create_table "holders", :force => true do |t|
t.string "faceid"
t.timestamps
end
add_index "holders", ["badges_id"], :name => "index_holders_on_badges_id"
create_table "badges", :force => true do |t|
t.string "name"
t.text "description"
t.timestamps
end
create_table "badges_holders", :force => true do |t|
t.integer "holder_id"
t.integer "badge_id"
t.timestamps
end
Now you can easily use Holder.find_by_faceid('xyz').badges to find the all hedges held by the holder whose faced is xyz. And Badge.first.holders to get all the holders for the first bedge.
For your question HABTM will be a good option as you do not need any extra field in the join table, so you can just use has_and_belongs_to_many in both of your models and you don't need BadgesHolder model in that case. And for the migration of the join table, replace first line with create_table "badges_holders", :id => false, :force => true do |t| a and remove t.timestamps as the join table for HABTM should not have any other column than the foreign keys.
If it's some Ruby on Rails, you must have 2 models :
class Holder < ActiveRecord:Base
has_many :badges
end
class Badge < ActiveRecord:Base
belongs_to :holder
end
Your entry called badges_id should not be in your holders table ; you should have a holder_id on your "badges" table.
Then, you can simply call
Holder.find_by_faceid('foobar').badges
and
Badge.find(1337).holder
If your badge can belongs to many holders, then you have to write a has_and_belongs_to_many relation.
I have three models in my Rails 3 application, DailyData and DailyDataVehicle and Vehicle, a many to many relationship.
I just learned that if you update the model with the associations, that it doesn't update the database, so I am going back and adding those migrations. I am also lucky enough to confidently think I know the differences between belongs_to and has_many, however, in my migration file, I am not sure that t.references does.
So I named the migration model AddDailyDataToDailyDataVehicle, and want to add the dailyData_id to the daily_data_vehicles table. This is a many to many relationship, so I want the id key to be in the relationship table DailyDataVehicles, but I'm not quite sure that t.references will know that.
Maybe I am slightly mixing up the class associations and the database relationships, and if I am, then please clarify this.
If t.references is not what I want, do I have to declare the relationship manually with has_many, and if so, what is the syntax for that?
schema file currently:
create_table "daily_data_vehicles", :force => true do |t|
t.integer "vehicle_id"
t.datetime "created_at", :null => false
t.datetime "updated_at", :null => false
end
add_index "daily_data_vehicles", ["vehicle_id"], :name => "index_daily_data_vehicles_on_vehicle_id"
Migration (attempt):
class AddDailyDataToDailyDataVehicle < ActiveRecord::Migration
def change
change_table :dailyDataVehicles do |t|
t.references :dailyData
end
add_index :dailyDataVehicles, :dailyData_id
end
end
What I think the schema file should look like if the migration works correctly:
create_table "daily_data_vehicles", :force => true do |t|
t.integer "vehicle_id"
t.integer "dailyData_id"
t.datetime "created_at", :null => false
t.datetime "updated_at", :null => false
end
add_index "daily_data_vehicles", ["vehicle_id"], :name => "index_daily_data_vehicles_on_vehicle_id"
add_index "daily_data_vehicles", ["dailyData_id"], :name => "index_daily_data_vehicles_on_daily_data_id"
with the difference being t.integer "dailyData_id" and add_index "daily_data_vehicles", ["dailyData_id"], :name => "index_daily_data_vehicles_on_daily_data_id"
class AddDailyDataToDailyDataVehicle < ActiveRecord::Migration
def change
add_column :daily_data_vehicles, : daily_data_id, :integer
add_index :daily_data_vehicles, :daily_data_id
end
end
class DailyDataVehicle < ActiveRecord::Base
belongs_to :daily_data
end
class DailyData < ActiveRecord::Base
has_many :daily_data_vehicles
end
I'm getting the error unknown attribute: user_id durring execution of current_user.stories.build
class User < ActiveRecord::Base
has_many :stories, class_name: 'Story', foreign_key: 'user_id', dependent: :destroy
...
class Story < ActiveRecord::Base
belongs_to :user, class_name: 'User', foreign_key: 'user_id'
...
schema.rb
create_table "stories", :force => true do |t|
t.string "responsible"
t.string "descr"
t.string "state"
t.datetime "created_at", :null => false
t.datetime "updated_at", :null => false
end
create_table "users", :force => true do |t|
t.string "email"
t.string "password_digest"
t.datetime "created_at", :null => false
t.datetime "updated_at", :null => false
t.string "name"
end
It doesn't contain 'user_id' field. Any ideas?
Kulbir is correct that you need to define a user_id column in your stories table, but doesn't explain the way to do that.
The correct way to make that change is to create a new migration. By convention, it should be called add_user_id_to_stories and would be created as follows (assuming you're using Rails 3+):
rails generate migration add_user_id_to_stories
If you run that, it should actually generate a migration that already contains the change you need to make, which should be something like:
add_column :stories, :user_id, :integer
As an aside when you're following the Rails conventions concerning association naming, which you are, you can actually skip a lot of the extra specification. In the User model, you can specify just has_many :stories and in the Story model specify belongs_to :user. Rails will assume the same class names and foreign keys you've specified.
You should have a user_id field in your stories table like below to define the association in your models.
create_table "stories", :force => true do |t|
t.integer "user_id"
t.string "responsible"
t.string "descr"
t.string "state"
t.datetime "created_at", :null => false
t.datetime "updated_at", :null => false
end
...
end
Edit
Check Emily's answer for detailed explanation.
you should use the new syntax and pass the fieldtype as symbol
add_column :stories, :user_id, :integer
I'm trying to set up a new project for a music site. I'm learning ROR and am a bit confused about how to make join models/tables. Does this look right?
I have users, playlists, songs, and comments. Users can have multiple playlists. Users can have multiple comments on their profile. Playlists can have multiple songs. Playlists can have comments. Songs can have comments.
class CreateTables < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :login
t.string :email
t.string :firstname
t.string :lastname
t.timestamps
end
create_table :playlists do |t|
t.string :title
t.text :description
t.timestamps
end
create_table :songs do |t|
t.string :title
t.string :artist
t.string :album
t.integer :duration
t.string :image
t.string :source
t.timestamps
end
create_table :comments do |t|
t.string :title
t.text :body
t.timestamps
end
create_table :users_playlists do |t|
t.integer :user_id
t.integer :playlist_id
t.timestamps
end
create_table :playlists_songs do |t|
t.integer :playlist_id
t.integer :song_id
t.integer :position
t.timestamps
end
create_table :users_comments do |t|
t.integer :user_id
t.integer :comment_id
t.timestamps
end
create_table :playlists_comments do |t|
t.integer :playlist_id
t.integer :comment_id
t.timestamps
end
create_table :songs_comments do |t|
t.integer :song_id
t.integer :comment_id
t.timestamps
end
end
def self.down
drop_table :users
drop_table :playlists
drop_table :songs
drop_table :comments
drop_table :users_playlists
drop_table :users_comments
drop_table :playlists_comments
drop_table :songs_comments
end
end
Few things:
Short version:
Join tables should be alphabetical (e.g. create_table :comments_users
This is only one half of setting up your associations. I'd like to see your model code as well
Your comments model should be setup to be a polymorphic association to the others.
Long version:
When setting up a join table (e.g. users and comments) you want to make it alphabetical. So that the users/comments table is actually create_table :comments_users. Ideally, you would want to setup a more meaningful name for this join table (since it is a model - see below) but it's your call.
Remember that you have to create models for these :has_many through associations. Most of these join tables could be created with :has_and_belongs_to_many but for future expansions, may as well use the :has_many through method. It would be wise to provide your association code in your model files as well - just as important as the creation of tables.
For comments, think about polymorphic relationships. This is because the comments are the same across all the different tables it belongs to. What this does is look for a type column in the polymorphic join table and that tells it what table the record (i.e. comment) belongs to.
Starting Resources:
Check out Ryan's brilliant (as usual) Railscast on the subject:
http://railscasts.com/episodes/47-two-many-to-many
Also, on polymorphism:
http://railscasts.com/episodes/154-polymorphic-association
http://guides.rubyonrails.org/association_basics.html
That looks ok. You seem to have the ID's in all the right place.
Couple of points though:
It's often easier to have many small migrations. I generally create each model and migration individually. You can then start building your model relationships in lock-step with your tests to ensure that your business requirements are actually being implemented.
You have some tests, right? :)