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-