vatsrahul1001 commented on PR #51952: URL: https://github.com/apache/airflow/pull/51952#issuecomment-2996182478
That’s a fair point — I agree that keeping the cleanup logic simple and explicit (especially in a critical area like deletions) is worth the trade-off in maintainability. I have added FK relationship in our already existing [tableconfig].(https://github.com/astronomer/airflow/blob/1f5f48114ff1b3cc7dfa0e261b934d1ddba2bec8/airflow-core/src/airflow/utils/db_cleanup.py#L107) > Interesting approach. > > I could approve easly but I have a small caveat and consideration. > > I would love for others to take a look and I would likely just hard-code the relationships if I were implementing it (they are very, unlikely to change and we do not have many of those). > > I wonder if there is no ready to use tools /libs that already do that (sounds like a problem that many people might have) and maybe we should look for it rather than using our code that looks complex'ish. And I am not entirely sure if the inspector will sufficiently abstract away the DB structure - there might be some subtle behavioural differences between different databases and I can imagine that this code starts failing because of some "small" changes in Postgres or MySQL in the future, or not working in some past versions of those. > > Alternatively - maybe we can - rather than having all the topological sort, simply hardcode the sequences of deletion of tables and sort deletion according to it? > > That sounds like way more maintainable, less code, less complexity and easier to reason about. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@airflow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
