Question

I was hoping I could get feedback on major changes to how a model works in an app that is in production already.

In my case I have a model Record, that has_many PhoneNumbers.

Currently it is a typical has_many belongs_to association with a record having many PhoneNumbers.

Of course, I now have a feature of adding temporary, user generated records and these records will have PhoneNumbers too.

I ‘could’ just add the user_record_id to the PhoneNumber model, but wouldn’t it be better for this to be a polymorphic association?

And if so, if you change how a model associates, how in the heck would I update the production database without breaking everything? >.<

Anyway, just looking for best practices in a situation like this.

Thanks!

Answer 1

There’s two approaches that might help you with this.

One is to introduce an intermediate model which handles collections of phone numbers. This way your Record and UserRecord can both belong_to this collection model and from there phone numbers and other contact information can be associated. You end up with a relationship that looks like this:

class Record < ActiveRecord::Base
  belongs_to :address_book
  delegate :phone_numbers, :to => :address_book
end

class UserRecord < ActiveRecord::Base
  belongs_to :address_book
  delegate :phone_numbers, :to => :address_book
end

class AddressBook < ActiveRecord::Base
  has_many :phone_numbers
end

This kind of re-working can be done with a migration and a bit of SQL to populate the columns in the address_books table based on what is already present in records.

The alternative is to make UserRecord an STI derived type of Record so you don’t need to deal with two different tables when defining the associations.

class Record < ActiveRecord::Base
  has_many :phone_numbers
end

class UserRecord < Record
end

Normally all you need to do is introduce a ‘type’ string column into your schema and you can use STI. If UserRecord entries are supposed to expire after a certain time, it is easy to scope their removal using something like:

UserRecord.destroy_all([ 'created_at<=?', 7.days.ago ])

Using the STI approach you will have to be careful to scope your selects so that you are retrieving only permanent or temporary records depending on what you’re intending to do. As UserRecord is derived from Record you will find they get loaded as well during default loads such as:

@records = Record.find(:all)

If this causes a problem, you can always use Record as an abstract base class and make a derived PermanentRecord class to fix this:

class PermanentRecord < Record
end

Update during your migration using something like:

add_column :records, :type, :string
execute "UPDATE records SET type='PermanentRecord'"

Then you can use PermanentRecord in place of Record for all your existing code and it should not retrieve UserRecord entries inadvertently.