Hi All, Following the discussion in [1] and [2], which deal with the problem that views cannot be dropped under default configurations,
*The problem* ----------- Two feature flags interact here: *DROP_WITH_PURGE_ENABLED* default: false *PURGE_VIEW_METADATA_ON_DROP* default: true Dropping a view internally passes purge=true whenever PURGE_VIEW_METADATA_ON_DROP is enabled, and that request then hits the DROP_WITH_PURGE_ENABLED guard in the shared drop path. With the defaults above, the two contradict each other and every view drop fails with 403 Forbidden, even though the caller never asked for a purge. So out of the box, views cannot be dropped at all. Operators have to discover and flip one of the two flags to get a working view lifecycle. *Possible solutions* ------------------ 1. Change the default of PURGE_VIEW_METADATA_ON_DROP to false. The current changes in PR [2] Views become droppable out of the box and the two defaults stop contradicting each other. The trade-off is that purging view metadata would then require both flags to be enabled, which keeps the two flags coupled like it is today preserving the current behaviour. 2. Narrow DROP_WITH_PURGE_ENABLED to tables only. The guard would no longer apply to views, leaving PURGE_VIEW_METADATA_ON_DROP as the single, independent control for view metadata purging. This decouples the two settings, at the cost of changing what DROP_WITH_PURGE_ENABLED covers today. There is also an existing integration test asserting the current coupled behaviour, linked in the issue [1] 3. Maybe something else or some combination of the two, for example narrowing the scope and also revisiting the default. Let me know what folks think about this!!! -Ayush [1] https://github.com/apache/polaris/issues/5293 [2] https://github.com/apache/polaris/pull/5322
