[
https://issues.apache.org/jira/browse/PHOENIX-7190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17813458#comment-17813458
]
ASF GitHub Bot commented on PHOENIX-7190:
-----------------------------------------
palashc commented on code in PR #1807:
URL: https://github.com/apache/phoenix/pull/1807#discussion_r1475430210
##########
phoenix-core-client/src/main/java/org/apache/phoenix/schema/MetaDataClient.java:
##########
@@ -898,9 +898,9 @@ public MetaDataMutationResult updateCache(PName tenantId,
List<String> functionN
* @return true if the PTable contained by result was modified and false
otherwise
* @throws SQLException if the physical table cannot be found
*/
- private boolean addColumnsAndIndexesFromAncestors(MetaDataMutationResult
result, Long resolvedTimestamp,
- boolean
alwaysAddAncestorColumnsAndIndexes,
- boolean
alwaysHitServerForAncestors)
+ private boolean
addColumnsIndexesAndLastDDLTimestampsFromAncestors(MetaDataMutationResult
result, Long resolvedTimestamp,
Review Comment:
> This way there is only one place in the code where we are adding
information from the ancestors.
@tkhurana What if updateCache is not called for the index table directly? If
the client resolves just the base table for a query, this method will not
execute for the index, right? One thing we could do is to create a new PTable
in the case of tables with a new list of indexes inside it which have the
ancestor map.
##########
phoenix-core-client/src/main/java/org/apache/phoenix/schema/MetaDataClient.java:
##########
@@ -898,9 +898,9 @@ public MetaDataMutationResult updateCache(PName tenantId,
List<String> functionN
* @return true if the PTable contained by result was modified and false
otherwise
* @throws SQLException if the physical table cannot be found
*/
- private boolean addColumnsAndIndexesFromAncestors(MetaDataMutationResult
result, Long resolvedTimestamp,
- boolean
alwaysAddAncestorColumnsAndIndexes,
- boolean
alwaysHitServerForAncestors)
+ private boolean
addColumnsIndexesAndLastDDLTimestampsFromAncestors(MetaDataMutationResult
result, Long resolvedTimestamp,
Review Comment:
> This way there is only one place in the code where we are adding
information from the ancestors.
@tkhurana What if updateCache is not called for the index table directly? If
the client resolves just the base table for a query, this method will not
execute for the index, right? One thing we could do is to create a new PTable
in the case of tables with a new list of indexes inside it which have the
ancestor map.
> Changes made to base table directly are not visible to the view.
> ----------------------------------------------------------------
>
> Key: PHOENIX-7190
> URL: https://issues.apache.org/jira/browse/PHOENIX-7190
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: Rushabh Shah
> Assignee: Palash Chauhan
> Priority: Major
>
> Steps to reproduce:
> 1. Create base table table1 with columns: PK1, V0, V1, V2
> 2. Create view view1 on the base table as SELECT * from table1;
> 3. Run SELECT * from view1; --> This will cache PTable of view1 on the client
> side. This will resolve all the columns of the base table and cache it in
> view's PTable.
> 4. Run ALTER table table1 DROP COLUMN V1;
> This will update the last ddl timestamp of table1
> 5. Run SELECT * from table1;
> Server will throw StaleMetadataCacheException and it will fetch the latest
> PTable of the base table from server and cache it on client.
> 6. Run SELECT V1 from view1;
>
> Expected behavior:
> Client should encounter ColumnNotFoundException since we remove V1 from the
> base table.
>
> Actual behavior:
> Client doesn't throw any Exception
>
> Why?
> The client is using the PTable object of view1 which was cached after step 3.
> During the query execution, client will validate last ddl timestamp of the
> table and the view.
> Client has upto date last ddl timestamp of the view1 after step 3
> Client has upto date last ddl timestamp of the base table after 5.
> Thats why the select query in step6 didn't fail.
> Solution:
> While caching the view on the client side, we should also store the last ddl
> timestamp of the whole hierarchy inside view's PTable object. While
> validating last ddl timestamp of the view, we should validate the last ddl
> timestamp of the hierarchy which is cached inside view's PTable but the view
> was resolved sometime in the past.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
