Solved (at least for now): I used the composite primary keys plugin but listed only a single (and fake) primary key: set_primary_keys :doc_id # note plural!
:doc_id is not a PK, and for this logging table it's possible there is no combination of columns that will yield a single row, depending on the timing of multi- inserts. But the insert now works and I can move on! Jeff On Oct 19, 3:14 pm, JeffV <[email protected]> wrote: > I tried the composite_primary_keys (2.3.2) plugin, with the same > overall result: I cannot insert a row (via Postgres) into a table > without a PK. My model now has this line: > set_primary_keys :doc_id, :user_id, :view_date, :view_time # > legacy tbl, include all cols > > My insert error is thus: > Mcolumn "doc_id,user_id,view_date,view_time" does not exist > P170 > Fparse_expr.c > L421 > RtransformColumnRef: INSERT INTO "document_ref_access" ("doc_id", > "user_id", > "view_date", "view_time") VALUES (1, E'W:5:a_name', '2009-10-19', > '2009-10-1 > 9 14:52:11.605227') RETURNING "doc_id,user_id,view_date,view_time") > > The RETURNING clause seems to be causing the problem. If I set the PK > to, say, :doc_id (mind you this col is NOT a PK for this table) the > insert works but the doc_id col is set to NULL. Any other suggestions? > > Thanks, > Jeff > > On Oct 16, 12:32 pm, Marnen Laibow-Koser <rails-mailing-l...@andreas- > > > > s.net> wrote: > > 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-Koserhttp://www.marnen.org > > [email protected] > > -- > > Posted viahttp://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 -~----------~----~----~----~------~----~------~--~---
