[
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)
