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
For whatever reason there might be, client DDL may choose not to use the ON DELETE CASCADE clause on foreign key definitions, yet cascading deletes are still desirable. jOOQ has all the required meta information to implement this recursively, and efficiently.
In particular, jOOQ's implementation would only run a single query per table (using semi joins to the original delete command), unlike what might be implemented by users, which would effectively be the N+1 problem.
Some databases might have native support for a CASCADE clause on the DELETE statement. If so, we could take inspiration from their syntax (and definitely generate the syntax instead of emulating it).
We'll look into this more globally in the context of "synthetic DDL" (#9526), as for that latter issue, we'll need some additional infrastructure to correctly model compound statments (see #9645)
For whatever reason there might be, client DDL may choose not to use the
ON DELETE CASCADE
clause on foreign key definitions, yet cascading deletes are still desirable. jOOQ has all the required meta information to implement this recursively, and efficiently.In particular, jOOQ's implementation would only run a single query per table (using semi joins to the original delete command), unlike what might be implemented by users, which would effectively be the N+1 problem.
Some databases might have native support for a
CASCADE
clause on theDELETE
statement. If so, we could take inspiration from their syntax (and definitely generate the syntax instead of emulating it).See: https://stackoverflow.com/q/49551385/521799
The text was updated successfully, but these errors were encountered: