These are chat archives for edbirmingham/network

22nd
Jun 2016
Errin Larsen
@errinlarsen
Jun 22 2016 17:43 UTC
Hi @saabdoli ! Good to meet you, today. I hope you enjoy Ruby and Rails. I'll "join" this room and try to help out if you run into Ruby/Rails questions.
saabdoli
@saabdoli
Jun 22 2016 20:53 UTC
Hi @errinlarsen ! Right now, I'm working on an Event Type resource that should be associated to the Event Class. Essentially, users should be able to create event types, and then later select those event types from a dropdown when they create an event. Currently they choose from a static list defined in the model. If I understand this correctly, I should create a migration to make this change. Does that sound correct to you? @anthonycrumley as well.
saabdoli
@saabdoli
Jun 22 2016 21:57 UTC
Something like AddProgramIdToNetworkEvents?
Errin Larsen
@errinlarsen
Jun 22 2016 22:12 UTC
What are the models involved (and why aren't they named the same thing you're talking about)?
I see a NetworkEvent model -- is that an "Event"?
what is a Program? (perhaps I'm not viewing the correct branch...)
Assuming that "Event" => NetworkEvent, and "Event Type" => Program, then I would agree with your migration name (above) with a slight modification. I would type ...
Errin Larsen
@errinlarsen
Jun 22 2016 22:17 UTC
rails generate migration AddProgramsToNetworkEvents program:references
I believe that will accomplish what you are looking for. You should end up with a migration like:
class AddProgramsToNetworkEvents < ActiveRecord::Migration
  def change
    add_reference :network_events, :program, index: true
  end
end
... i.e. you will have created a One-to-Many relationship between a Program and zero or more NetworkEvents -- in other words, every NetworkEvent will have at most 1 Program, and every Program will have (potentially) multiple NetworkEvents
Errin Larsen
@errinlarsen
Jun 22 2016 22:23 UTC
... and then, you would need to add the line belongs_to :program in app/models/network_event.rb, and has_many :network_events to app/models/program.rb
saabdoli
@saabdoli
Jun 22 2016 22:23 UTC
Sorry, yes. I meant the NetworkEvent. Great, I'd already added the relationships to the classes.
Errin Larsen
@errinlarsen
Jun 22 2016 22:24 UTC
:+1: yay!
saabdoli
@saabdoli
Jun 22 2016 22:25 UTC
OK, thanks for the help. I'll also have to generate a migration to drop to previous column, correct?
Errin Larsen
@errinlarsen
Jun 22 2016 22:25 UTC
(btw: that references is some Rails magic. What it will actually do is add a program_id column to the network_events table as a foreign key, as well as adding an index on that column for that table.)
well, you can add it to the same migration... hold on a sec...
saabdoli
@saabdoli
Jun 22 2016 22:26 UTC
using drop?
Errin Larsen
@errinlarsen
Jun 22 2016 22:33 UTC
... so, it's complicated (lol)
The method to call, remove_column, is not "reversible", so you would need to modify the migration further to use #up and #down blocks, instead of a #change block (if that makes sense).
At this point, your original thought, using another migration to remove the column, would be easier
... in that case, rails generate migration RemoveEventTypeFromNetworkEvents event_type:string would generate the migration you're looking for. It would look something like this...
class RemoveEventTypeFromNetworkEvents < ActiveRecord::Migration
  def up
    remove_column :network_events, :event_type
  end

  def down
    add_column :network_events, :event_type, :string
  end
end
saabdoli
@saabdoli
Jun 22 2016 22:39 UTC
So the down and up blocks ensure that the migration is reversible. Cool. Thanks.
And down is executed when the migration is rolled back?
Errin Larsen
@errinlarsen
Jun 22 2016 22:39 UTC
... however, I might be giving you old info (!!). I know that the "reversible" stuff is true for Rails 3, but they might have fixed that for Rails 4. I would have to experiment to be sure (I've been scouring the Google results, but I'm still not sure without trying it myself).
... but, the up/down stuff is still applicable in Rails 4 (i.e. you won't go wrong doing as above). I would be interested in what rails generate migration RemoveEventTypeFromNetworkEvents event_type:string produces (whether or not it creates up/down blocks, or a change block, I mean)
Errin Larsen
@errinlarsen
Jun 22 2016 22:48 UTC
oh -- and yes, the up block gets run when you run the migration, the down block when you roll it back. You can use this to write any ruby code you want in those blocks. For example, you could run a loop through all the current NetworkEvents in the system in the up block, before the remove_column call, to grab the current event_type and update the record with the proper program_id. Then, in the down block, you can set the proper event_type for the record, after the add_column call, based on the current program_id for the record.
saabdoli
@saabdoli
Jun 22 2016 22:52 UTC
Cool. Thanks so much for the help!
The generated migration creates a change block. Should I add the up and down blocks to make it reversible?
Errin Larsen
@errinlarsen
Jun 22 2016 22:58 UTC
nope - I saw a couple of posts that mentioned that Rails 4 was OK with remove_column in a change block. I think you're fine, I just wasn't sure. I would trust the rails generate migration output.
Have you discovered the Rails Guides, yet? (http://guides.rubyonrails.org/active_record_migrations.html) The ActiveRecord Migrations page has a lot of good info
we have been discussing the topics covered by 3.8, 3.9, and 3.10 on that page (starting here: http://guides.rubyonrails.org/active_record_migrations.html#using-the-change-method)
... with all that being said, re-reading those sections makes me believe I was right and wrong. in other words, it will remove the column for you in the change block, as you expect, but it will have trouble if you ever do decide to roll that migration back. Again, I'm not sure. I'd need to experiment.