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