I''ve been bringing up a good basica framework for applications at work. To give decent security I''ve been implementing the Rails Recipie for Authorization of function calls modeled on the book''s implementation. (Changes for our environment were added..but are minor.) Since I initially let Rails create the join table between two data tables with a HABTM relationship....I assumed it would know HOW to do it correctly. Oh well...maybe not. My tables looked like this: Rights ID name Roles ID rolename Rights_Roles ID right_id role_id The ID field is basically unneeded since this table is only for the many to many relationship. I was getting a problem when trying to add a second record to the table. It turns out the HABTM relationship was adding one of the foreign keys as the ID field as well as it''s true field....causing a key constraint conflict. My solution was to use a migration to alter the table and drop the ID field. My rights_roles relationship now seems to be working just fine. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Oh yeah...I had been running on the stable version of Rails 1.1. I thought that I might have a bug and decided to upgrade to Edge Rails. (Since I''ve heard Rails 1.2 isn''t far off...it should be fairly close and I might get a fix for this.) Nope....no dice. Just FYI. Hope this helps somebody else in this situation. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Steve Keener wrote:> > Oh yeah...I had been running on the stable version of Rails 1.1. I > thought that I might have a bug and decided to upgrade to Edge Rails. > (Since I''ve heard Rails 1.2 isn''t far off...it should be fairly close > and I might get a fix for this.) Nope....no dice. Just FYI. > > Hope this helps somebody else in this situation.although it doesn''t specify it in the docs, you are NOT suppose to have an ID field in the join table. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
i''ve had this same problem recently. if you use migrations, the ID field is created automatically. there is a way to bypass the ID primary key creation in the migration but I don''t remember where I read about it - anyone? ed On 12/7/06, Justin Mazzi <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > Steve Keener wrote: > > > > Oh yeah...I had been running on the stable version of Rails 1.1. I > > thought that I might have a bug and decided to upgrade to Edge Rails. > > (Since I''ve heard Rails 1.2 isn''t far off...it should be fairly close > > and I might get a fix for this.) Nope....no dice. Just FYI. > > > > Hope this helps somebody else in this situation. > > although it doesn''t specify it in the docs, you are NOT suppose to have > an ID field in the join table. > > -- > Posted via http://www.ruby-forum.com/. > > > >-- Ed Hickey Developer Litmus Media 816-533-0409 ehickey-A4HEbNdjHgMmlAP/+Wk3EA@public.gmane.org A Member of Think Partnership, Inc www.ThinkPartnership.com Amex ticker symbol: THK --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Justin Mazzi wrote:> although it doesn''t specify it in the docs, you are NOT suppose to have > an ID field in the join table.I kinda figured that out. Hence the reason I figured I''d post it so somebody else doesn''t have to go through the mental gymnastics I did. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Steve Keener wrote:> Justin Mazzi wrote: >> although it doesn''t specify it in the docs, you are NOT suppose to have >> an ID field in the join table. > > I kinda figured that out. Hence the reason I figured I''d post it so > somebody else doesn''t have to go through the mental gymnastics I did.yeah, im just confirming that this isnt a work around or something. this is how its suppose to work, -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Justin Mazzi wrote:> Steve Keener wrote: >> Justin Mazzi wrote: >>> although it doesn''t specify it in the docs, you are NOT suppose to have >>> an ID field in the join table. >> >> I kinda figured that out. Hence the reason I figured I''d post it so >> somebody else doesn''t have to go through the mental gymnastics I did. > > yeah, im just confirming that this isnt a work around or something. this > is how its suppose to work,Damn. I must be smarter than I look. :-) (I''d kinda have to be....heheh) -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Ed Hickey wrote:> i''ve had this same problem recently. if you use migrations, the ID > field is created automatically. there is a way to bypass the ID > primary key creation in the migration but I don''t remember where I > read about it - anyone? > > ed > >create_table "join_table", :id => false -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Found the wiki reference to the join table issue:
http://wiki.rubyonrails.org/rails/pages/has_and_belongs_to_many
This is the example given on how to create the join table - The :id =>
false prevents the ID field from being created.
class TranzactionRelations < ActiveRecord::Migration
def self.up
create_table :tranzaction_relations, :id => false do |t|
t.column :invoice_id, :integer
t.column :payment_id, :integer
end
add_index :tranzaction_relations, [:invoice_id]
add_index :tranzaction_relations, [:payment_id]
end
def self.down
drop_table :tranzaction_relations
end
end
--
Posted via http://www.ruby-forum.com/.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
On 12/7/06, Steve Keener <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > I''ve been bringing up a good basica framework for applications at work. > To give decent security I''ve been implementing the Rails Recipie for > Authorization of function calls modeled on the book''s implementation. > (Changes for our environment were added..but are minor.) > > Since I initially let Rails create the join table between two data > tables with a HABTM relationship....I assumed it would know HOW to do it > correctly. Oh well...maybe not. My tables looked like this: > > Rights > ID > name > > Roles > ID > rolename > > Rights_Roles > ID > right_id > role_id > > The ID field is basically unneeded since this table is only for the many > to many relationship. I was getting a problem when trying to add a > second record to the table. It turns out the HABTM relationship was > adding one of the foreign keys as the ID field as well as it''s true > field....causing a key constraint conflict. > > My solution was to use a migration to alter the table and drop the ID > field. My rights_roles relationship now seems to be working just fine.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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Yeah...I just didn''t find anything quickly and figured somebody would find this as annoying as I did. It''s trivial to fix, but figuring out what''s going on, researching to see if I was delusional, and then just trying it without the ID field....took more time than I want to admit. :-) -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
This is a my #1 most hated rails bug. The framework should not make you choose between good db design and simple code. Further this is as about as far from the principle of least surprise as you can get. The workaround is to add :select => ''table.*'' to your habtm declaration. Also FWIW, I highly recommend you always add primary keys to all your tables. This will make it much easier (as opposed to horribly painful) later when they do (and they often do) become first class model objects and costs you basically nothing. pt. On 12/7/06, Steve Keener <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > I''ve been bringing up a good basica framework for applications at work. > To give decent security I''ve been implementing the Rails Recipie for > Authorization of function calls modeled on the book''s implementation. > (Changes for our environment were added..but are minor.) > > Since I initially let Rails create the join table between two data > tables with a HABTM relationship....I assumed it would know HOW to do it > correctly. Oh well...maybe not. My tables looked like this: > > Rights > ID > name > > Roles > ID > rolename > > Rights_Roles > ID > right_id > role_id > > The ID field is basically unneeded since this table is only for the many > to many relationship. I was getting a problem when trying to add a > second record to the table. It turns out the HABTM relationship was > adding one of the foreign keys as the ID field as well as it''s true > field....causing a key constraint conflict. > > My solution was to use a migration to alter the table and drop the ID > field. My rights_roles relationship now seems to be working just fine. > > -- > Posted via http://www.ruby-forum.com/. > > > >-- Parker Thompson http://www.parkert.com/ 510.541.0125 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 12/9/06, Jeremy Evans <jeremyevans0-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > 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> Jeremy > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Isak Hansen wrote:> It''s not a bug, habtm join tables are working as intended. If a join > model is what you want, use has_many :through.You say Tomato.... :-)> 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.Obviously it''s not the best design. And I''d rather NOT add complexity by either using the surrogate key....or adding the composite key''s gem....when I really should need it to make this work. So far just removing the ID field has allowed my code to work. Keeping it simple because I''m not that bright. :-) When you start adding fields or gems to make a simple concept work then you are NOT following the simplest idea behind RoR....to work AS EXPECTED. When you do it the ''right'' way you start sounding like a java guru. JMNSHO MudDawg -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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.Edit for typo.... -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 12/10/06, Isak Hansen <isak.hansen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > On 12/9/06, Jeremy Evans <jeremyevans0-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > 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.> > > Isak > > > > Jeremy > > > > > > > > > > >-- Parker Thompson http://www.parkert.com/ 510.541.0125 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 12/10/06, Steve Keener <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > 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> Edit for typo.... > > -- > Posted via http://www.ruby-forum.com/. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I just ran into this as well. See this thread: http://www.ruby-forum.com/topic/92440 Sigh. Thanks for all of the discussion - it''s very helpful. Wes -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Parker Thompson wrote:> This is a my #1 most hated rails bug. The framework should not make > you choose between good db design and simple code. Further this is as > about as far from the principle of least surprise as you can get. > > The workaround is to add :select => ''table.*'' to your habtm > declaration. >Do you literally mean add :select => ''table.*'' to the declaration or does "table" represent something? How does this help and why does it fix the inserts into the join table? Thanks, Wes -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Wes Gamble wrote:> Parker Thompson wrote: >> This is a my #1 most hated rails bug. The framework should not make >> you choose between good db design and simple code. Further this is as >> about as far from the principle of least surprise as you can get. >> >> The workaround is to add :select => ''table.*'' to your habtm >> declaration. >> > > Do you literally mean add :select => ''table.*'' to the declaration or > does "table" represent something? > > How does this help and why does it fix the inserts into the join table? > > Thanks, > WesOK, I''m a dummy - of course you meant to put actual table names. However, this does not change the behavior that Steve describes. Wes -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Seemingly Similar Threads
- Naming rights_roles join model using has_many :through and polymorphic associations
- Strange HABTM behavior against SQL Server (AR 1.14.4)
- Composite Primary Keys
- Saving ActiveRecord in PostgreSQL without id
- Model.find(:first, :lock=>true) Unknown key(s) :lock