Re: postgres adapater problem with create_table :id => false

Marnen Laibow-Koser
Wed, 21 Oct 2009 16:18:09 -0000

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
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
>
> Jeff
>
> On Oct 21, 12:50�am, Marnen Laibow-Koser <rails-mailing-l...@andreas-

--
Posted via http://www.ruby-forum.com/.