hi folks
When using push_with_attributes , after inserting some bulk of data I get
duplicate ids, after examining the logs, I notice it was using ramdom values
for id column.
After changing the sentence to be something like:
packages.push_with_attributes myobj, { :type => blah, :modifier =>
modifier, :id => nil }
the id went auto-incremental again,
What is the reason ofthis behaviour?
Cheers
Duncan
On 13-okt-2005, at 18:09, Duncan Mac-Vicar Prett wrote:> > hi folks > > When using push_with_attributes , after inserting some bulk of data > I get > duplicate ids, after examining the logs, I notice it was using > ramdom values > for id column. > > After changing the sentence to be something like: > packages.push_with_attributes myobj, { :type => blah, :modifier => > modifier, :id => nil } > > the id went auto-incremental again, > > What is the reason ofthis behaviour?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!!). -- Julian "Julik" Tarkhanov
> 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.
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