HABTM join table quirk

This is a long standing bug in Rails that I don't think they plan on
fixing. See http://dev.rubyonrails.org/ticket/1031. The suggested
workaround if you want to use a primary key in a join table is to
change to has_many :through. There is a plugin for Rails 1.1 that
works around the bug:
http://wiki.rubyonrails.org/rails/pages/Allow+HABTM+Primary+Key+Plugin.

Jeremy

This is a long standing bug in Rails that I don't think they plan on
fixing. See http://dev.rubyonrails.org/ticket/1031. The suggested
workaround if you want to use a primary key in a join table is to
change to has_many :through. There is a plugin for Rails 1.1 that
works around the bug:
http://wiki.rubyonrails.org/rails/pages/Allow+HABTM+Primary+Key+Plugin.

It's not a bug, habtm join tables are working as intended. If a join
model is what you want, use has_many :through.

Adding a surrogate key to a pure join table _certainly_ isn't good db
design. You'll probably want a composite primary key from the two
columns to avoid duplicates.

Isak

>
> This is a long standing bug in Rails that I don't think they plan on
> fixing. See http://dev.rubyonrails.org/ticket/1031. The suggested
> workaround if you want to use a primary key in a join table is to
> change to has_many :through. There is a plugin for Rails 1.1 that
> works around the bug:
> http://wiki.rubyonrails.org/rails/pages/Allow+HABTM+Primary+Key+Plugin.
>

It's not a bug, habtm join tables are working as intended. If a join
model is what you want, use has_many :through.

This is a bug. Features can be turned off.

Regardless, this 'feature' has surprised, confused, and flustered many
a developer. In this regard it minimally violates the spirit of the
framework. Saying "it's supposed to work that way" misses the point.
The goal is to take the pain out of web development and this is
painful.

Adding a surrogate key to a pure join table _certainly_ isn't good db
design. You'll probably want a composite primary key from the two
columns to avoid duplicates.

I beg to differ. I (and many others) would argue tables should always
have a primary key that has no other use (i.e. don't use composite
keys or keys like SSNs which you *think* won't change but sometimes
do, are harder to index, etc). If you don't you will almost certainly
have messy data problems later.

pt.

Steve Keener wrote:
> either using the surrogate key....or adding the composite key's
> gem....when I really SHOULDN'T need it to make this work.

I never mentioned a composite key gem, HABTM associations work fine
out of the box..

I think I was being fairly specific about why I'd add a db level pk
constraint, but if you don't believe in those things, by all means
leave it out.

Isak