Feat: orphanedRowAction=disabled (rebase of PR 8285)

[jbjhjm]

@pleerock

This is a new PR based on orphanedRowAction=skip PR #8285

Fixes #8275

Implementation is as before, just rebased to include commits added in the meantime.
Also, instead of keyword "skip" it is now using "disabled", as discussed in other PR.

[pleerock]

take new option into quotes

[pleerock]

disable must be "disable"

[pleerock]

Tests are failing....

[jbjhjm]

@pleerock postgres test fails because of unexpected data, but this must be a quirk within relation update mechanism.
As you can see in PR file diff, the change only touches handling of removedRelatedEntitySubject.
Should I just simplify the test so that it passes with postgres too?

Shortened info on what is happening:

const userToUpdate = (await userRepo.findOne(userId))!;
userToUpdate.settings = [
  userToUpdate.settings[0],
  // create modified version of setting at index 1
  { ...userToUpdate.settings[1], data:"bar_updated" },
];
await userRepo.save(userToUpdate);

then the user is fetched again and its settings entries are checked.
(only) on postgres, userToUpdate.settings[1] will not have been updated.

[pleerock]

@jbjhjm not sure I understand the problem

[jbjhjm]

@jbjhjm not sure I understand the problem

Postgres test fails because it didn't persist changes on related item correctly.
Problem seems unrelated to this PR as it only changes handling of removedRelatedEntitySubject.
I can take another look but I have no idea about postgres and its quirks.

[pleerock]

Also it looks weird that test is only failing for postgres version 12

[pleerock]

@jbjhjm did you upgrade to 0.3.0 ? Maybe we can make it 0.3.0 feature? I'm going to stop accepting PRs for 0.2.x very soon and release 0.3.0

[jbjhjm]

Oh, I was not aware of 0.3.0 @pleerock ! Let's continue with 0.2.x but I'll also open a mirrored PR for the 0.3.0 branch, ok?

[ivansieder]

I've been digging into some issues related to unwanted nullified references for quiet some hours until I came across this issue :D

just for reference, I'm adding another use-case for this PR (thank you @jbjhjm in the meantime for your effort you've put into this PR). We have soft-deletion in place (a custom one due to how other applications handled it in the past) and when updating one-to-many relations and not passing some soft-deleted children, it tries to set it's reference to null, even if it should just ignore it.

So looking really forward to this pull request :)

[pleerock]

@jbjhjm sorry to annoy you again, but I would like to ask you to rebase it against latest master, since latest master is 0.3.0 already, and I don't have plans to accept new PRs into 0.2.0

[jbjhjm]

@pleerock will do but it'll take some time, haven't even touched 0.3.x yet due to the breaking changes and tight time.

[pleerock]

@jbjhjm np

[jbjhjm]

@pleerock alright, I ported it to current master. I was not able to run any local tests, getting a Jscript error popup stating typeorm cli.js contains an error. No idea. Are tests currently run on CircleCI? I see only lint + build checks here.

[pleerock]

you need to run prettier to fix lint issues. Also please merge latest master into your branch again because it contains few important fixes on tests are running in CI.

[jbjhjm]

fixed, looks good @pleerock

[jbjhjm]

@pleerock @AlexMesser please check. I did half a dozen rebases for this due to waiting time and I really don't want to do it another time.

[pleerock]

thanks you for all your efforts and patience @jbjhjm

[nrathi]

@jbjhjm sorry to bother you, I'm having trouble understanding this option you added.

I have a parent & child entity (renamed to "Document" and "Page" for this example). I want to ensure the following:

1. A page is never an orphan -- it's always associated with a document, and if something would jeopardize that, an error is thrown. Is this correctly accomplished by orphanedRowAction: "disable"?
2. The pages belonging to a document must be unique in page_number. Is this correctly accomplished by @Unique("document_page_number", ["document", "page_number"])?

@Entity("document")
export class Document {
  @OneToMany(() => Page, (listing) => listing.pages, {
    eager: true,
    cascade: true,
  })
  pages!: Page[];

@Entity("page")
@Unique("document_page_number", ["document", "page_number"])
export class Page  {
  @ManyToOne(() => Document, (item) => item.pages, {
    nullable: false,
    orphanedRowAction: "disable",
  })
  document!: Document;

  @Column()
  page_number!: number;
}

[jbjhjm]

Hi @nrathi , I think orphanedRowAction is not what you are looking for.
It controls typeOrm's behavior when SAVING an entity which contains a OneToMany property.

To prevent deletion of a Document that still has Pages assigned, take a look at the "onDelete" option.
It depends on native database features however, so it may work differently in your project than in mine (mysql/mariaDb).
I suggest to set onDelete = "NO ACTION". This will make the database driver throw an error when trying to delete a row which still has references in other table rows (foreign key constraints.)

Also take a look at this: #8277
In that issue, I summed up all documentation, hints and my own experiences all around configuring Relations.

About the @Unique setup, I don't have helpful knowledge about that.

Good luck!