summaryrefslogtreecommitdiff
path: root/_posts/2011-12-09-same-class-associations-in-rails-3.html
blob: 654f69d0d24623bd5cc409af9da6edc3bcb7c555 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
---
layout: post
title: Same class associations in Rails 3
tags:
- Development
status: publish
type: post
published: true
meta:
  _edit_last: '1'
  _cws_is_markdown: '1'
---
<strong>[TL;DR]</strong> Even though the selected events conceptually belong to a record, the latter has the foreign keys to former. So technically, <code>has_one</code> is to be changed to <code>belongs_to</code>.

<hr />

This is the first time I've ran into something like this and it was interesting to realize what it actually means when developing a business logic in Rails.

<h3>Context</h3>

In this app I'm building, I have <em>Students</em> that have a <em>Record</em> per year. Each record has several <em>Events</em>. These records also have two specific events: a <em>test</em> and an <em>audition</em>, registered in the schema as <code>id</code>'s in the record's table.

<h3>So what did technically happen?</h3>

I wasn't able to access those specific events through the associations specified in the model. Given <code>r = Record.first</code>, when I tried to access the audition, by using <code>r.test</code>, Rails would use a SQL query that would correspond to <code>r.events.first</code> instead.

After acknowledging that, I turned to <a href="http://twitter.com/varandas">@varandas</a> and we both thought it might be a bug in the Rails framework. Turns out it wasn't; all I had to do was switch from <code>has_one</code> to <code>belongs_to</code> (thanks <a href="http://github.com/drogus">@drogus</a>!). The reason for that is the foreign key is on the <code>records</code> table. From the framework's perspective, it looks like the record actually <em>belongs to</em> the event, when in practice it's not.

<h3>Code sample</h3>

[gist id=1449428]