Cascade not behaving as expected during update, child object delete attempted

TypeORM version: 0.1.0-alpha.32

Here are my example classes:

@Entity()
export class User {

  @PrimaryGeneratedColumn()
  id?: number;

  @OneToOne(type => Location, location => location.user, {
    nullable: true,
    cascadeAll: true
  })
  @JoinColumn({
    name: 'locationId'
  })
  location?: Location;
}

@Entity()
export class Location {
  @PrimaryGeneratedColumn()
  id?: number;

  @Column({
    length: '128',
    nullable: true
  })
  name?: string;

  @OneToOne(type => User, user => user.location, {
    nullable: true
  })
  user?: User;
}

I make changes to the user.location property on a loaded user object and then persist the user class, expecting the location updates to cascade:

this.getEntityManager().getRepository(User).persist(user).then((oo) => {});

Which results in a delete being called (presumably to delete the old location and then create a new one to associate?)

DELETE FROM location WHERE id=? – PARAMETERS: [1]

However, as you can see from above, the user own the relationship and the location relation isn’t removed first. This results in:

ER_ROW_IS_REFERENCED_2: Cannot delete or update a parent row: a foreign key constraint fails (public.user, CONSTRAINT fk_974a227a147ad9c2fc91304adc4 FOREIGN KEY (locationId) REFERENCES location (id))

In any case, a delete should never occur in the first place. An update should occur on the location object. It doesn’t appear to be doing this. I reduced the problem and changed it such that all I do is load up the user object with the relation and then persist it unchanged…same issue:

debug: executing query: START TRANSACTION debug: executing query: UPDATE user SET locationId=?, updatedAt=?, version=? WHERE id=? – PARAMETERS: [1,“2017-07-19T06:37:23.314Z”,4,2] debug: executing query: DELETE FROM location WHERE id=? – PARAMETERS: [1] error: query failed: DELETE FROM location WHERE id=? – PARAMETERS: [1] debug: executing query: ROLLBACK error: JwtAuthPlugin(): update user: failed Error: ER_ROW_IS_REFERENCED_2: Cannot delete or update a parent row: a foreign key constraint fails (schema.user, CONSTRAINT fk_974a227a147ad9c2fc91304adc4 FOREIGN KEY (locationId) REFERENCES location (id)) at Query.Sequence._packetToError (/Users/arimus/workspace/new/node_modules/mysql/lib/protocol/sequences/Sequence.js:52:14) at Query.ErrorPacket (/Users/arimus/workspace/new/node_modules/mysql/lib/protocol/sequences/Query.js:77:18) at Protocol._parsePacket (/Users/arimus/workspace/new/node_modules/mysql/lib/protocol/Protocol.js:280:23) at Parser.write (/Users/arimus/workspace/new/node_modules/mysql/lib/protocol/Parser.js:75:12) at Protocol.write (/Users/arimus/workspace/new/node_modules/mysql/lib/protocol/Protocol.js:39:16) at Socket.<anonymous> (/Users/arimus/workspace/new/node_modules/mysql/lib/Connection.js:103:28) at emitOne (events.js:96:13) at Socket.emit (events.js:188:7) at readableAddChunk (_stream_readable.js:176:18) at Socket.Readable.push (_stream_readable.js:134:10) -------------------- at Protocol._enqueue (/Users/arimus/workspace/new/node_modules/mysql/lib/protocol/Protocol.js:141:48) at PoolConnection.query (/Users/arimus/workspace/new/node_modules/mysql/lib/Connection.js:208:25) at MysqlQueryRunner.<anonymous> (/Users/arimus/workspace/new/src/driver/mysql/MysqlQueryRunner.ts:160:32) at step (/Users/arimus/workspace/new/node_modules/typeorm/driver/mysql/MysqlQueryRunner.js:32:23) at Object.next (/Users/arimus/workspace/new/node_modules/typeorm/driver/mysql/MysqlQueryRunner.js:13:53) at fulfilled (/Users/arimus/workspace/new/node_modules/typeorm/driver/mysql/MysqlQueryRunner.js:4:58) at propagateAslWrapper (/Users/arimus/workspace/new/node_modules/async-listener/index.js:421:23) at /Users/arimus/workspace/new/node_modules/async-listener/glue.js:188:31 at /Users/arimus/workspace/new/node_modules/async-listener/index.js:458:70 at process._tickDomainCallback (internal/process/next_tick.js:129:7)

I may be missing something silly, but pretty sure this wasn’t an issue in previous versions.

Note: if I set only to cascadeUpdate, things appear to behave better (no delete attempted). However, I do want cascade inserts and deletes to occur when users are created / deleted.

[arimus]

No worries. I appreciate all the hard work you put into this already. I’m sure everyone does.

I’m taking a look now and hopefully I’ll find a reasonable stop gap to getting some of the basic use cases for cascading updates / deletes working. Will update with my results or lack thereof if I give up 😉

[arimus]

And I must be tired. My problem has the same potential issue and it’s not as deterministic as I was shooting for. Have an alternate solution I’ll be posting soon. Still trying to determine if I can get the remove() function to behave first.