Has_two, has_three, etc

Rails
1

I was wondering what the community thought about an extension to the
associations mechanism which allowed declarations like:

class Game < AR::Base

has_two :referees

end

I have run across this situation fairly frequently. An object has a
defined number of subobjects of a particular type. In this situation I
don’t necessarily want to use habtm or has_many :through. The join
table just adds overhead to things like validation and ensuring that
there are not more than 2 referees attached to the game, etc.

This would be implemented db fields like referee_1_id,
referee_2_id,etc…

This approach simplifies forms and object creation in the contexts
where it is appropriate.

If I had a list of referees, I could just do a collection_select for
each referee, rather than having to worry about link up other records
through a join table.

Obviously this approach only applies to situations where there are a
defined number of subobjects, but I find this to be a fairly common
occurrence.

Thoughts, comments?

2

On 16 Apr 2008, at 15:10, Andrew S. wrote:

I have run across this situation fairly frequently. An object has a
defined number of subobjects of a particular type. In this situation I
don’t necessarily want to use habtm or has_many :through. The join
table just adds overhead to things like validation and ensuring that
there are not more than 2 referees attached to the game, etc.

I can’t say I’ve felt the need for something like this very often. But
stick in a plugin and who knows, it might take off!

Fred

3

I’m with Fred: I haven’t really needed something like this but I can
see the value of it. If you were gonna roll your own plugin for this,
I’d suggest generalizing it a bit more. Maybe something like:

has_some :referees, :count => 2

Then it would look for referee_1_id and referee_2_id, just like you
wrote. But then you could dynamically define the number.

Of course, it occurs to me that you are very tightly wedded to the DB
in this case. I.e. if you want to change to three referees, you’d need
to update the DB to add another FK field. And, the “has_many” or
“has_one” puts the FK on other table. It’s “belongs_to” that puts
the FK on the current table.

So maybe a better way to think about this is that it uses a normal
has_many or habtm relationship but adds some constraints on it. I.e.
if I set :count => 2, then trying to add a 3rd to the association
would fail.

Just some thoughts off the top of my head.

-Danimal

On Apr 16, 8:22 am, Frederick C. [email protected]

4

Hello,

you could simply put in your Game model :

belongs_to :referee_1, :class_name => ‘Referee’
belongs_to :referee_2, :class_name => ‘Referee’

But the problem is in the Referee model, what you would want is :

has_one :game

but that doesnt work because you have in fact two possible columns for
the foreign key in the games table, leading to all the problems “Clever
Neologism” mentionned.

Now if you want to be able to get the game the referee is assigned to
(but ONLY in read mode), you could put in your Referee model :

def game
Game.find(:first, :conditions=>"referee_1_id = “+id.to_s+” or
referee_2_id = "+id.to_s)
end

of course the language itself doesn’t make it read only… so be careful
:slight_smile:

5

On Apr 16, 10:10 am, Andrew S. [email protected] wrote:

defined number of subobjects of a particular type. In this situation I
don’t necessarily want to use habtm or has_many :through. The join
table just adds overhead to things like validation and ensuring that
there are not more than 2 referees attached to the game, etc.

You are going to have to add “belongs_to_many” as well as “has_two”…
if your game table has referee ids in it, then a game belongs_to a
referee (not what you would expect, but that’s the way it is). The
problem will come in when you say referee.game = somegame (or
referee.games << game) or game.referees << referee, because a referee
has_two (or five, whatever) games. Which column should these
operations reference and change in the games table? In other words,
if you assign a referee to a game, which of the already assigned
referees should be replaced? It’s going to get ugly quick: you’ll
have to have some kind of either pre-named function to do that for you
(that would be hardcoded), or pass in a block. It’s a lot of work for
a thin veneer of syntactic sugar… unless you have 10 or 20 of
something, you really just need to write the 10 lines of code. This
is probably why this feature doesn’t exist.

Either you would have to break bi-directional referencing between your
models (clearly not optimal), or write the replacement policy yourself
(what you are having to do now anyway). It’s just not something
where there is really only one correct way to do it. The same applies
to modifying habtm with a :limit parameter or something like that,
which if you had to do it some way, that’s what I would use, and throw
an exception if you try to add too many things. I.e. force the user
to take a referee away before adding if there are already two.

Here’s the proper (IMO) way to do it:

:habtm :referees do
def addreferee
(guard against too many referees)
end
#I have never tried this, but you might be able to overload
operators using this
def <<(ref)
end
end

or:

:habtm :referees, :before_add => :validate_refs

def validate_refs()
#Check count
end

In the Rails RDocs, checkout
ActiveRecord::Associations::ClassMethods.

Relevant sections are “Association Callbacks” and “Association
Extensions”. If you do decide to write a plugin, this is probably the
file to look at and mimic (probably using one of the methods above to
modity HABTM relationship with a :limit parameter).