Issue type:

[x] question
[?] bug report
[ ] feature request
[ ] documentation issue

Database system/driver:

[ ] cordova
[ ] mongodb
[ ] mssql
[ ] mysql / mariadb
[ ] oracle
[x] postgres
[ ] cockroachdb
[ ] sqlite
[ ] sqljs
[ ] react-native
[ ] expo

TypeORM version:

[ ] latest
[ ] @next
[x] 0.2.12

Steps to reproduce or a small repository showing the problem:

Let's say I have the following two entities (simplified for demonstration purposes):

@Entity()
export class A {
  @PrimaryGeneratedColumn('uuid')
  readonly id: string;

  @OneToOne(() => B, b => b.a, { nullable: true })
  readonly b: B | null;
}

@Entity()
export class B {
  @PrimaryColumn()
  readonly id: string;

  @OneToOne(() => A, a => a.b)
  @JoinColumn({ name: 'id' })
  readonly a: A;
}

Running schema:log or migration:generate on a blank database shows that TypeORM generates both a primary key as well as a unique key for B.id. It's clear why TypeORM would want to add a unique key constraint on a column which represents a 1:1 relation in general, but in this case the column already has a primary key and therefore I'd think the unique key is redundant. If my logic is sound then this is a bug :-) it also happens if entity B already existed previously and now I'm adding entity A and changing B.id from a generated UUID primary column to a join column for the new relation - the migration that is generated drops the default value of B.id, creates the appropriate table for A and the foreign key B("id") references A("id"), but also creates the unique key while leaving the existing primary key in place. (One other thing it does is DROP SEQUENCE "b_id_seq", which never existed as B.id is a UUID column and not a serial, but that's a separate issue.)

The question is therefore: is this the expected behaviour (as in "expected by design")? If so, why is that? Why wouldn't the primary constraint do the job? And if not, well, then like I said, I'd like to report a beetle sighting :-)