[ https://issues.apache.org/jira/browse/PHOENIX-6186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17221024#comment-17221024 ]
Chinmay Kulkarni edited comment on PHOENIX-6186 at 10/27/20, 12:28 AM: ----------------------------------------------------------------------- [~gjacoby] As far as naming goes, I agree with [~bharathv] on the name being indicative of a last modification time related to schema shape as you mentioned in your description. Also may be useful to indicate that it is a server ts. I see you have mentioned that this Jira wouldn't consider any parent/child activity, but are we considering changes to child views based on alterations to the parent schema like an add column to the parent being inherited by its children? Such column inheritance would change the shape of the child view schema though the change is not made synchronously. For example, adding a column to a base table would cascade and get inherited by all child views that haven't diverged. In pre-4.15 clients this is generally also a physical change in the metadata rows for those child views. Post-4.15 however, we avoid synchronous changes to descendants when ancestors change (since they could be on different regions of SYSTEM.CATALOG), but it is a change in the "final" schema of the view nevertheless. What is the expectation of the value of this timestamp when such changes occur? was (Author: ckulkarni): [~gjacoby] As far as naming goes, I agree with [~bharathv] on the name being indicative of a last modification time related to schema shape as you mentioned in your description. I see you have mentioned that this Jira wouldn't consider any parent/child activity, but are we considering changes to child views based on alterations to the parent schema like an add column to the parent being inherited by its children? Such column inheritance would change the shape of the child view schema though the change is not made synchronously. For example, adding a column to a base table would cascade and get inherited by all child views that haven't diverged. In pre-4.15 clients this is generally also a physical change in the metadata rows for those child views. Post-4.15 however, we avoid synchronous changes to descendants when ancestors change (since they could be on different regions of SYSTEM.CATALOG), but it is a change in the "final" schema of the view nevertheless. What is the expectation of the value of this timestamp when such changes occur? > Store table metadata last modified timestamp in PTable / System.Catalog > ----------------------------------------------------------------------- > > Key: PHOENIX-6186 > URL: https://issues.apache.org/jira/browse/PHOENIX-6186 > Project: Phoenix > Issue Type: New Feature > Reporter: Geoffrey Jacoby > Assignee: Geoffrey Jacoby > Priority: Major > Fix For: 4.16.0 > > Attachments: PHOENIX-6186-4.x.patch > > > There are many reasons why it's useful to know when a particular table's > metadata was last modified. It's helpful when solving cache coherency > problems, and also in order to interact with external schema registries which > may have multiple versions of a particular schema and require a timestamp to > resolve ambiguities. > This JIRA will add a last modified timestamp field to System.Catalog, to be > updated both when creating a table/view and also when adding or removing a > column. Changing purely internal Phoenix properties will not update the > timestamp. -- This message was sent by Atlassian Jira (v8.3.4#803005)