On 10/13/05, Jeremy Evans
<jeremyevans0-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:> > Do NOT use id column on join tables. This will get you into some big
> > trouble (items inside the collection of the owner object will have
> > the IDs of join rows!!).
>
> Alternatively, add ''attributes.delete("id")''
right before the sql
> statement in
ActiveRecord::Associations::HasAndBelongsToManyAssociation#insert_record.
> There is a patch that is more flexible in
> http://dev.rubyonrails.com/ticket/1031, but it may be out of date.
>
> There is no reason that Rails should restrict you from using primary
> keys on join tables, especially if you are using rich associations.
> I''m not sure if the devs consider this a rails
"opinion", but I
> consider it a bug. It''s been known about since at least April, and
the
> fix is fairly simple. Hopefully it''ll get squashed before 1.0.
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
I see this situation as an escape from the intenion of HABTM. If
there is "ANY" data that needs to be trapped on the join table, then
it is no longer a HABTM but just a trio of tables with has_many,
belongs_to relationships. I don''t see this as a problem.... I
personally would be waay more confused (and I have seen this in the
past in other architectures) to have data "apparently" connected to
another table to only find out that there is no entity to store the
data, which is _actually_ being maintained in a join table. When the
architecture hides a detail like this, it makes groking an
implementation design very very difficult.
I recommend dropping HABTM for these tables and joining them appropriately.
"Principle of Least Surprise"
Regards,
Peter Fitzgibbons