Description
Issue description
Issues with migrations after type to upgrade typeorm from 0.2.31 to 0.3.20
Expected Behavior
We have a large-ish database with lots of tables, with some @ManyToMany and @OneToOne annotations on various columns, with some of the many-to-many relationships using @JoinTable annotations.
Some of our entity files don't specify onDelete configurations, which means that with typeorm 0.2.31, the entities and corresponding junction tables were defaulting to onDelete: "CASCADE" / ON DELETE CASCADE, while the default for onUpdate seemed to be "NO ACTION".
With #5714 and #8616 (the 0.3.0 pull request), the default for onUpdate changed to "CASCADE".
I would have expected that upgrading typeorm from 0.2.31 to 0.3.20 would have resulted in no new migration file being created when npx typeorm migration:generate (with appropriate other arguments), or at least no new migration file after adding in any relevant onDelete and onUpdate configurations.
Actual Behavior
After adjusting for the new type changes in the 0.3.x release, when trying to generate a new migration file, initially one was being generated with constraints for some ManyToMany and OneToOne relationships that were being dropped and re-added with ON DELETE CASCADE ON UPDATE CASCADE whereas previously they were just ON DELETE CASCADE.
We're very hesitant to change our junction tables from ON UPDATE NO ACTION to ON UPDATE CASCADE, so I was trying to make changes in our code base to get back to ON UPDATE NO ACTION.
It was possible to remove the forward/regular side of the dropped and re-added constraints for the ManyToMany relationships from the generated migration file by adding explicit onUpdate: "NO ACTION" cascade options (and sometimes also onDelete: "CASCADE").
However, specifying the other side of a ManyToMany relationship (and also specifying the cascade options on that other side of the relationship) doesn't seem to do anything. e.g. if entity A specifies a ManyToMany relationship with entity B via a join/junction table of a_b, specifying the inverse ManyToMany relationship on entity B with cascade options doesn't seem to change the migration file.
There are some OneToOne relationships that also seem to have a similar issue as the ManyToMany relationships, but specifying onUpdate: "NO ACTION" doesn't appear to change anything in the migration file. There are also some unique constraints (indexes) being removed for these OneToOne relationships, probably due to collateral damage by typeorm when dropping constraints and re-adding constraints for the cascade changes.
We have downgraded back to typeorm 0.2.31 until this is solved. While we would like to stick with typeorm if possible, we have also started looking at alternative options.
Steps to reproduce
I can try and reproduce this in a small repository later, if necessary.
My Environment
| Dependency | Version |
|---|---|
| Operating System | macOS and Alpine Linux |
| Node.js version | 18.15.0 and 18.18.2 |
| Typescript version | 5.3.3 |
| TypeORM version | 0.3.20 |
Additional Context
Is there a particular reason that ON DELETE CASCADE and ON UPDATE CASCADE was chosen as the default for junction tables as opposed to ON DELETE NO ACTION and ON UPDATE NO ACTION?
Given that the PostgreSQL database defaults to NO ACTION for both ON DELETE and ON UPDATE, does it make sense to change the default for ON UPDATE and ON DELETE on junction tables to be NO ACTION (instead of CASCADE) for at least PostgreSQL and maybe other databases too?
I have a draft pull request for doing this for ManyToMany relationships in PostgreSQL in #10859 (one of the tests is not passing, since it assumes that the default is ON DELETE CASCADE). This would probably be a breaking change, and might warrant a new minor version, if merged.
As noted below, I'm happy to help with pull requests. I believe I have a rough understanding of what is happening in ManyToMany relationships in the JunctionEntityMetadataBuilder.ts module, at least with regards to the onDelete and onUpdate configuration, but pointers to the code that handles the OneToOne relationships would be helpful.
Relevant Database Driver(s)
- aurora-mysql
- aurora-postgres
- better-sqlite3
- cockroachdb
- cordova
- expo
- mongodb
- mysql
- nativescript
- oracle
- postgres
- react-native
- sap
- spanner
- sqlite
- sqlite-abstract
- sqljs
- sqlserver
Are you willing to resolve this issue by submitting a Pull Request?
Yes, I have the time, but I don't know how to start (with regards to the OneToOne relationships). I would need guidance.