You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 withtypeorm
0.2.31, the entities and corresponding junction tables were defaulting toonDelete: "CASCADE"
/ON DELETE CASCADE
, while the default foronUpdate
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 whennpx typeorm migration:generate
(with appropriate other arguments), or at least no new migration file after adding in any relevantonDelete
andonUpdate
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
andOneToOne
relationships that were being dropped and re-added withON DELETE CASCADE ON UPDATE CASCADE
whereas previously they were justON DELETE CASCADE
.We're very hesitant to change our junction tables from
ON UPDATE NO ACTION
toON UPDATE CASCADE
, so I was trying to make changes in our code base to get back toON 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 explicitonUpdate: "NO ACTION"
cascade options (and sometimes alsoonDelete: "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 aManyToMany
relationship with entity B via a join/junction table ofa_b
, specifying the inverseManyToMany
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 theManyToMany
relationships, but specifyingonUpdate: "NO ACTION"
doesn't appear to change anything in the migration file. There are also some unique constraints (indexes) being removed for theseOneToOne
relationships, probably due to collateral damage bytypeorm
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 withtypeorm
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
Additional Context
Is there a particular reason that
ON DELETE CASCADE
andON UPDATE CASCADE
was chosen as the default for junction tables as opposed toON DELETE NO ACTION
andON UPDATE NO ACTION
?Given that the PostgreSQL database defaults to
NO ACTION
for bothON DELETE
andON UPDATE
, does it make sense to change the default forON UPDATE
andON DELETE
on junction tables to beNO ACTION
(instead ofCASCADE
) 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 isON 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 theJunctionEntityMetadataBuilder.ts
module, at least with regards to theonDelete
andonUpdate
configuration, but pointers to the code that handles theOneToOne
relationships would be helpful.Relevant Database Driver(s)
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.The text was updated successfully, but these errors were encountered: