phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (PHOENIX-2941) Alternative means of propagating schema changes
Date Sat, 10 Jun 2017 01:41:18 GMT

     [ https://issues.apache.org/jira/browse/PHOENIX-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

James Taylor updated PHOENIX-2941:
----------------------------------
    Fix Version/s:     (was: 4.11.0)

> Alternative means of propagating schema changes
> -----------------------------------------------
>
>                 Key: PHOENIX-2941
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-2941
>             Project: Phoenix
>          Issue Type: Improvement
>            Reporter: Nick Dimiduk
>
> The current approach to propagating schema changes (ie, add column) involves maintaining
a [GlobalCache|https://github.com/apache/phoenix/blob/10909ae502095bac775d98e6d92288c5cad9b9a6/phoenix-core/src/main/java/org/apache/phoenix/cache/GlobalCache.java]
of table schema on both clients and in RS coprocessors. This schema information is versioned,
and query timestamp is used to determine when the cache is considered stale and needs updated.
This causes problems for users who specify a timestamp either via connection settings (ie,
PHOENIX-2607) or using the ROW_TIMESTAMP feature. Presumably this will also negatively impact
users of the Tephra transaction system as it uses the cell timestamp to store transaction
id.
> We need some other means of propagating schema changes throughout the cluster. One approach
might be a ZK node for each table that can notify coprocessors (and clients?) that their cache
is stale.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message