I agree that the behaviors during add column and drop column on the parent are inconsistent and we should do the same thing in both scenarios. I'm not fully aware of the reasons behind doing things this way.
Since we have to do so in the case of drop column anyways, I'm leaning more towards just inheriting column modifications from parent to child views irrespective of whether the view has diverged or not and irrespective of whether the parent was a view or physical table. That being said, I'm not sure if there are use-cases that depend on the current behavior. Are there advantages to keeping it the way it is? To add to this confusion, this behavior has actually changed after 4.15. In 4.14, any columns dropped from a parent view (not physical table) are NOT dropped in its child views (diverged or not). However, as #3 mentions, this changes post 4.15. Similarly, in 4.14 any columns added to a parent view are NOT inherited by its child views (diverged or not), but columns added to a physical base table ARE inherited by all non-diverged child views. As #2 mentions, in 4.15 this also subtly changes. Overall, I believe Phoenix's view limitations during creation are the reason users would end up diverging in the first place. I don't think it's correct to tie that to column inheritance from parents which seem to be a different issue. Thanks, Chinmay On Tue, Nov 17, 2020 at 4:11 PM Geoffrey Jacoby <gjac...@apache.org> wrote: > I've run into an interesting quirk of Phoenix metadata while doing > PHOENIX-6186, which adds a "last DDL timestamp" to tables and views showing > the last time a table/view was created or had a column added or dropped. > > The quirk is the "diverged view" feature. Phoenix supports dropping a > column from a view that was originally inherited from a base table or > parent view. After that, the view is considered "diverged", which has > several effects, only the first of which is documented[1]. > > 1. The user-dropped column is missing from the diverged view (makes sense) > 2. Any column subsequently _added_ to the parent base table or a parent > view WILL NOT BE inherited by the child diverged view. (Surprising!) > 3. But any column subsequently _dropped_ from the parent base table or > parent view WILL be inherited by the child diverged view. (Really, really > surprising to me given #2) > > (Chinmay, please correct me if I got any of the above wrong. :-) ) > > I don't see how 2 follows from 1, or how 3 follows from 1 and 2. (I could > _maybe_ see protecting a diverged view from drops, because that can break > queries, but that's not the behavior here.) This would make me less likely > to actually use this feature. > > I'm told this made the splittable system catalog effort harder, and it > makes my current work difficult, since a diverged view can't just take the > max of it and its ancestors' last DDL timestamps to resolve at read time. I > also can't set the right value at DDL time because in a splittable syscat > world I can't update the view header row when the base table adds a column > because the table and view metadata could be in different regions. > > So before I have to choose between several not-great options to preserve > this diverged view behavior, I thought I'd ask: since it's undocumented, > and seems counter-intuitive to me, what do we lose by changing it instead? > Are there use cases where this is helpful or that have been built expecting > this behavior? > > Thanks, > > Geoffrey > [1] Limitation 5 in http://phoenix.apache.org/views.html#Limitations > -- Chinmay Kulkarni
