Thanx everyone for the feedback so for. I think the current sentiment is towards [2] I have updated the PR with [2], Will update in case the discussion drifts towards any other solution :-)
-Ayush On 2026/08/24 17:19:54 Yufei Gu wrote: > +1 on option 2. I asked for a dev mailing thread because this is a behavior > change. I'd suggest more people review this to avoid any surprises. > > Thanks Alex for the ideas! I'd postpone the renaming and new feature flags > to avoid additional behavior changes. > > Yufei > > > On Mon, Aug 24, 2026 at 6:46 AM Alexandre Dutra <[email protected]> wrote: > > > Hi Ayush, > > > > Thanks for raising this issue. > > > > I think that option 2 is cleaner, and I'd also advocate to rename > > DROP_WITH_PURGE_ENABLED to PURGE_TABLE_METADATA_ON_DROP for clarity. > > > > That said, if there is concern about narrowing down the scope of > > DROP_WITH_PURGE_ENABLED, I could also see a 3rd option: > > > > - Introduce a new PURGE_TABLE_METADATA_ON_DROP flag (default false). > > - To purge a table, require PURGE_TABLE_METADATA_ON_DROP + > > DROP_WITH_PURGE_ENABLED > > - To purge a view, require PURGE_VIEW_METADATA_ON_DROP + > > DROP_WITH_PURGE_ENABLED > > > > In this option, DROP_WITH_PURGE_ENABLED becomes a higher-level flag > > that stops all purges at once, while the other two flags gate the > > feature for tables or views only. > > > > Thanks, > > Alex > > > > On Mon, Aug 24, 2026 at 3:06 PM Jean-Baptiste Onofré <[email protected]> > > wrote: > > > > > > Hi Ayush > > > > > > That's a known issue, and I consider as a bug. For context, it's a > > > conflict defaults problem: DROP_WITH_PURGE_ENABLED=true (the guard) > > > plus PURGE_VIEW_METADATA_ON_DROP=true (the default behavior) means > > > views cannot be dropped at all out of the box (a 403 is thrown because > > > the drop internally requests purge=true but the purge guard blocks > > > it). > > > > > > I think option 2 is the best approach for a "real" long-term fix: > > > DROP_WITH_PURGE_ENABLED was almost designed as a safety guard for > > > table storage. Views don't have the same destructive storage > > > implications, so conflating them under one flag is a category error > > > imho. Scoping to tables only and letting PURGE_VIEW_METADATA_ON_DROP > > > stand on its own makes the intent of each flag unambiguous. > > > > > > I'm in favor of implementing #2 "quickly". > > > > > > Regards > > > JB > > > > > > On Sun, Aug 23, 2026 at 12:29 PM Ayush Saxena <[email protected]> > > wrote: > > > > > > > > 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 > > >
