[
https://issues.apache.org/jira/browse/PHOENIX-2885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15373320#comment-15373320
]
James Taylor commented on PHOENIX-2885:
---------------------------------------
If a column is dropped and a different client has the old metadata cached, the
query won't fail. It'll either return nothing (if the delete markers have been
placed) or return the data for the column for any rows where the delete marker
hasn't been placed yet.
If a table is dropped, we can detect that, but if a view is dropped we can't.
The same thing as above will happen.
> Refresh client side cache before throwing not found exception
> -------------------------------------------------------------
>
> Key: PHOENIX-2885
> URL: https://issues.apache.org/jira/browse/PHOENIX-2885
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Fix For: 4.9.0
>
>
> With the increased usage of the UPDATE_CACHE_FREQUENCY property to reduce
> RPCs, we increase the chance that a separate client attempts to access a
> column that doesn't exist on the cached entity. Instead of throwing in this
> case, we can update the client-side cache. This works well for references to
> entities (columns, tables) that don't yet exist. For entities that *do*
> exist, we won't detect that they've been deleted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
