It's confusing. I think we need the abstraction and generalization to support competition-like things better, but it does make the code more complicated. I've avoided the complication until now. To be honest, I had to study the code again before it made sense. Well, the pictures help me the most.
has_many :competition_event_memberships
has_many :source_events, :through => :competition_event_memberships, :source => :event
belongs_to :source_event, :class_name => "Event"
In Oregon Cup#source_results, we get all the "source event" IDs and put them into event_ids. The source events are the events that count for the Oregon Cup (Kings Valley, Table Rock RR, etc.) We use the event_ids in the WHERE clause of the SQL to grab results just from those events.
Events have many parent-child relationships. There's the one through the parent-children association, like the parent Cascade Cross Series and its SingleDayEvent children. And there are multiple competition-source_events associations: Kings Valley could be part of the Oregon Cup and the Womens Cat 4 Series.
Does that make more sense? It's one of those functional model things that don't have good real-world counterparts.
On May 13, 2009, at 5:17 PM, Ryan Rickerts wrote:
I guess I'm still confused by this domain model. I started adding a class in app/models/competitions/ (I forgot I did this for my Cascade Cross overall). This one I based on oregon_cup.rb as you suggest, but there's this big blob of SQL in the OregonCup#source_results method:
results = Result.find_by_sql(
%Q{SELECT results.id as id, race_id, racer_id, team_id, place FROM results
LEFT OUTER JOIN races ON races.id = results.race_id
LEFT OUTER JOIN categories ON categories.id = races.category_id
LEFT OUTER JOIN events ON races.event_id = events.id
WHERE races.category_id is not null
and place between 1 and 20
and categories.id in (#{category_ids_for(race)})
and (results.category_id is null or results.category_id in (#{category_ids_for(race)}))
and (events.id in (#{event_ids}) or events.parent_id in (#{event_ids}))
order by racer_id
}
)
The new join table CompetitionEventMemberships does not appear in this query, nor does the class have any logic other than the ActiveRecord assocations. So what purpose is it serving?
RyanR>
On Wed, May 13, 2009 at 4:00 PM, Ryan Rickerts
<edar...@gmail.com> wrote:
Also, I don't have a Competitions table, as "Coming Soon" suggests, with Event optional. I thought I had to use the Events table and provide a type that is available in routing (or I can add one? wish routing config worked in local).
RyanR>On Wed, May 13, 2009 at 3:55 PM, Ryan Rickerts
<edar...@gmail.com> wrote:
Then how is BAR different from RiderRankings if it is all Road? We only load results from Road right now, so effectively our RiderRankings==OBRA BAR, if I gather your explanation.
Sweet diagram.
RJR
On Wed, May 13, 2009 at 3:31 PM, Scott Willson
<sc...@butlerpress.com> wrote:
On May 13, 2009, at 3:05 PM, Ryan Rickerts wrote:
I can go with Event.type=Bar, and Event.discipline=Road? That makes it a BARR.
Only if you want to have the exact same rules and points as the OBRA BAR … which I think that you don't because the OBRA BAR counts
all road events, not just select ones.
Looks like this was attempted in our data in 2007, but there are no entries in the CompetitionEventMemberships table. I am looking forward to this!
Cool! Take a look at
the domain model (just remember that "Now" == "Old" and "Coming Soon" == "Now") and try using the OregonCup class as a guide. The Oregon Cup is pretty close to what you want, except that it's got some special category-mapping.