JeffV wrote: > The downside is pretty large: it doesn't work if I define a composite > PK. If you read my posting above you'll see that I get a Postgres > adapter error on the RETURNING statement.
No, your posting above says that you get the error when you define a *nil* PK, not a *composite* one. > That and the fact that this > is a logging table (in a legacy DB) with no PK(s). The columns are: > doc_id (not unique), user_id (not unique), date viewed (not unique), > and the combination is not unique. That's it! No PK. The combination is not unique? The same user could generate several records for the same doc with the *exact same* date viewed? It's not a timestamp? > It's not my > insistence, but rather the nature of a logging table. Um, no. It is simple to design a logging table where a unique index can be extracted. > A row in this > table is never updated, just INSERTs and SELECTs. I cannot add a > row_id column to this table as that would break many COBOL programs. Really? COBOL complains if all the data is there, but there's an extra column? > So that is life in the real world. The real world of bad DB design, maybe. > By claiming the table has a single > PK via "set_primary_keys" (note it's plural) it works. If you're claiming that the doc_id is the PK, then I'd be surprised if Rails would ever fetch more than one record per doc_id. Best, -- Marnen Laibow-Koser http://www.marnen.org [email protected] > > Jeff > > On Oct 21, 12:50�am, Marnen Laibow-Koser <rails-mailing-l...@andreas- -- 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 -~----------~----~----~----~------~----~------~--~---
