CODEWITHSUNDEEP
ruby-on-railsrubyoop
Laurens
Laurens

Reputation: 2088

Mandatory one-to-one relationship in Rails

I have a Flight class which represents a flight in a pilot's logbook. It is composed of the following attributes:

It also has an airport and time of both departure and arrival, which are related to my question.

I have though about modeling the the arrival and the departure as a Movement, which would be composed of the airport and the time. I would then derive a Departure and an Arrival class from the Movement, and have the Flight reference one of both.

Then I bumped into a discussion on Ruby's TrueClass and FalseClass (Why does Ruby have TrueClass and FalseClass instead of a single Boolean class?). The gist of it was that Ruby does not model true and false as a Boolean because they do not share any behavior and I believe the same goes for an arrival and a departure. They are exactly opposite even though they do share data.

Another option is that I simply embed the arrival and departure's data fields in the Flight. I find this awkward because that would mean that if you would traverse from the Airport model to the departures and arrivals (has_many :departures, has_many :arrivals) would yield a Flight model.

A third option I explored is creating separate Departure and Arrival models without inheriting from a Movement. However, since a Flight is required to have both and arrival and a departure, which are required to reference flight, we have created a nasty circular reference (which also plagues the first option, by the way).

How would I best model this relationship? Are there any alternatives I have failed to consider?

Upvotes: 0

Views: 155

Answers (2)

AJcodez
AJcodez

Reputation: 34236

If you want Arrival and Departure to share a lot of functionality, consider using an active support concern or an abstract parent class.

Inheritance:

class Movement < ActiveRecord::Base
  self.abstract_class = true
end

class Departure < Movement
end

Module:

http://www.fakingfantastic.com/2010/09/20/concerning-yourself-with-active-support-concern/

http://api.rubyonrails.org/classes/ActiveSupport/Concern.html

Upvotes: 1

Mark Swardstrom
Mark Swardstrom

Reputation: 18120

Speaking from a UI developer perspective, this is what I'd start with.

I suspect you will often do two things -

1) display the flight in a list and include the departure and arrival information in the list item 2) sort the list by time of departure and arrival

These will be easier/faster to do if the attributes are on the flight. You'll avoid the joins. Since the information is required, no need to 'has_one'. You can always move them later in a migration if you need to. Keep it simpler until the use cases come up.

I think it will also be easier for you to make a has_many :arrivals (which are of type Flight) on the airport by simply looking at the Flight's arrival airport id.

Upvotes: 1

Related Questions