JeffV wrote: > We have 30-40 tables in a legacy db with no PKs. These tables hold > various logging events and may be searched by a given day, a given > user id, a given event, etc., but not by a particular row id. So there > are reasonable reasons to not have PKs on all tables.
I think you're confusing the concept of a *surrogate* PK with a PK in general. Sure, in the case of your logging tables, it's probably reasonable not to have a separate Rails-style id field (surrogate PK). But it is advisable -- I'd even say essential -- to find some existing field or combination of fields that can be guaranteed unique for each record, and to declare them as a (perhaps composite) PK. > Unfortunately, > AR really like PKs... And so it should. If you don't want a surrogate PK, then declare some other field the PK. The composite_primary_keys plugin may help here. I maintain -- and I believe big-name DB gurus would say likewise -- that a table without *some* sort of PK is virtually always a Bad Thing, with or without Rails. . > If I set_primary_key nil I can't do a create (I get an interning empty > string error). If I set the PK to an arbitrary integer column then > that column is set to NULL (on an insert), despite its value being > passed in the attributes hash... I don't yet have a solution. See what composite_primary_keys will do for you. > > Jeff > > On Sep 16, 6:48�pm, Marnen Laibow-Koser <rails-mailing-l...@andreas- Best, -- Marnen Laibow-Koser http://www.marnen.org [email protected] -- 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
