Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delete Propagation to Parent Table for Joined Table Inheritance #11136

Open
snkuranga-candid opened this issue Mar 11, 2024 · 1 comment
Open
Labels
awaiting info waiting for the submitter to give more information use case not really a feature or a bug; can be support for new DB features or user use cases not anticipated

Comments

@snkuranga-candid
Copy link

Describe the use case

When a polymorphic table is created via joined table inheritance, I would expect that deleting a row in the subclass table would also delete the row in the parent table. I've found that when the subclass row is explicitly deleted, the delete propgates to the parent table as I would expect. However when the subclass row is deleted via cascading delete, that deletion doesn't propagate to the parent table. This leaves us in an undesirable state with several orphaned rows in the parent table. The only clear way of handling this I've found is to use event listeners in place of a proper cascading delete but ideally there should be a way to handle this so that cascading deletes are properly carried through to the parent table.

Databases / Backends / Drivers targeted

Postgresql / psycopg

Example Use

To give an example, imagine there are three tables:

Company
-------
id

Employee
------
id

Engineer(Employee)
------
id
company_id = Column(ForeignKey("company.id", ondelete="CASCADE"))

When a row in the engineer table is explicitly deleted, the related row in the Employee table is deleted successfully

session.delete(engineer) # This deletes the related Employee row without issue

When a row in the company table is deleted, the related row in the Engineer table is deleted but that deletion doesn't propagate to the Employee table and this is what I would like to be addressed

session.delete(company) # This deletes the related Engineer row but the Employee row remains

Additional context

We're using sqlalchemy version 1.4.31

@snkuranga-candid snkuranga-candid added requires triage New issue that requires categorization use case not really a feature or a bug; can be support for new DB features or user use cases not anticipated labels Mar 11, 2024
@CaselIT
Copy link
Member

CaselIT commented Mar 11, 2024

Hi,

I'm not sure how sqlalchemy should handle that case, since the foreign key cascades are handled by the db directly, meaning it's not sqlalchemy that's issuing a delete statement.

@CaselIT CaselIT added awaiting info waiting for the submitter to give more information and removed requires triage New issue that requires categorization labels Mar 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting info waiting for the submitter to give more information use case not really a feature or a bug; can be support for new DB features or user use cases not anticipated
Projects
None yet
Development

No branches or pull requests

2 participants