You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@phoenix.apache.org by ja...@apache.org on 2015/02/11 07:04:04 UTC
svn commit: r1658880 - in /phoenix/site: publish/recent.html
publish/roadmap.html publish/upgrading.html
source/src/site/markdown/recent.md source/src/site/markdown/roadmap.md
source/src/site/markdown/upgrading.md
Author: jamestaylor
Date: Wed Feb 11 06:04:04 2015
New Revision: 1658880
URL: http://svn.apache.org/r1658880
Log:
Update upgrading, roadmap, and recent features doc
Modified:
phoenix/site/publish/recent.html
phoenix/site/publish/roadmap.html
phoenix/site/publish/upgrading.html
phoenix/site/source/src/site/markdown/recent.md
phoenix/site/source/src/site/markdown/roadmap.md
phoenix/site/source/src/site/markdown/upgrading.md
Modified: phoenix/site/publish/recent.html
URL: http://svn.apache.org/viewvc/phoenix/site/publish/recent.html?rev=1658880&r1=1658879&r2=1658880&view=diff
==============================================================================
--- phoenix/site/publish/recent.html (original)
+++ phoenix/site/publish/recent.html Wed Feb 11 06:04:04 2015
@@ -1,7 +1,7 @@
<!DOCTYPE html>
<!--
- Generated by Apache Maven Doxia at 2015-01-31
+ Generated by Apache Maven Doxia at 2015-02-10
Rendered using Reflow Maven Skin 1.1.0 (http://andriusvelykis.github.io/reflow-maven-skin)
-->
<html xml:lang="en" lang="en">
@@ -134,6 +134,8 @@
</div>
<p>As items are implemented from our road map, they are moved here to track the progress weâve made:</p>
<ol style="list-style-type: decimal">
+ <li><b><a href="secondary_indexing.html#Functional_Indexes">Functional Indexes</a></b>. Enables an index to be defined as expressions as opposed to just column names and have the index be used when a query contains this expression.</li>
+ <li><b><a href="phoenix_mr.html">Map-reduce Integration</a></b>. Support general map-reduce integration to Phoenix by implementing custom input and output formats.</li>
<li><b><a href="update_statistics.html">Statistics Collection</a></b>. Collects the statistics for a table to improve query parallelization. <b>Available in our 3.2/4.2 release</b></li>
<li><b><a href="joins.html">Join Improvements</a></b>. Improve existing hash join implementation.
<ul>
Modified: phoenix/site/publish/roadmap.html
URL: http://svn.apache.org/viewvc/phoenix/site/publish/roadmap.html?rev=1658880&r1=1658879&r2=1658880&view=diff
==============================================================================
--- phoenix/site/publish/roadmap.html (original)
+++ phoenix/site/publish/roadmap.html Wed Feb 11 06:04:04 2015
@@ -1,7 +1,7 @@
<!DOCTYPE html>
<!--
- Generated by Apache Maven Doxia at 2015-01-31
+ Generated by Apache Maven Doxia at 2015-02-10
Rendered using Reflow Maven Skin 1.1.0 (http://andriusvelykis.github.io/reflow-maven-skin)
-->
<html xml:lang="en" lang="en">
@@ -135,19 +135,18 @@
<p>Our roadmap is driven by our user community. Below, in prioritized order, is the current plan for Phoenix:</p>
<ol style="list-style-type: decimal">
<li><b><a class="externalLink" href="https://issues.apache.org/jira/browse/PHOENIX-400">Transaction Support</a></b>. Support transactions by integrating with an open source solution like <a class="externalLink" href="https://github.com/continuuity/tephra">Tephra</a>, <a class="externalLink" href="https://github.com/XiaoMi/themis">Themis</a>, or some other similar option.</li>
+ <li><b><a class="externalLink" href="https://issues.apache.org/jira/browse/PHOENIX-1121">Monitoring and Management Improvements</a></b>. Though we support <a href="tracing.html">tracing</a> now, thereâs more work to do to round out our monitoring and management capabilities.</li>
+ <li><b><a class="externalLink" href="https://issues.apache.org/jira/browse/PHOENIX-1177">Cost-based Query Optimization</a></b>. Enhance existing <a href="update_statistics.html">statistics collection</a> by enabling further query optmizations based on the size and cardinality of the data.
+ <ul>
+ <li><b><a class="externalLink" href="https://issues.apache.org/jira/browse/PHOENIX-1178">Generate histograms</a></b> to drive query optimization decisions such as secondary index usage and join ordering based on cardinalities to produce the most efficient query plan.</li>
+ </ul></li>
<li><b><a class="externalLink" href="https://issues.apache.org/jira/browse/PHOENIX-1167">Join Improvements</a></b>. Enhance our join capabilities in a variety of ways:<br />
<ul>
<li><b><a class="externalLink" href="https://issues.apache.org/jira/browse/PHOENIX-1556">Table-stats-guided choice between hash join and sort-merge join</a></b>. Base hash join versus many-to-many decision on how many guideposts will be traversed for RHS table(s).</li>
<li><b><a class="externalLink" href="https://issues.apache.org/jira/browse/PHOENIX-150">Inlined parent/child joins</a></b>. Optimize parent/child joins by storing child rows inside of a parent row, forming the column qualifier through a known prefix plus the child row primary key.</li>
</ul></li>
<li><b><a href="subqueries.html">Subquery</a> Enhancement</b>, which includes support for <b><a class="externalLink" href="https://issues.apache.org/jira/browse/PHOENIX-1388">correlated subqueries in the HAVING clause</a></b> and <b><a class="externalLink" href="https://issues.apache.org/jira/browse/PHOENIX-1392">using subqueries as expressions</a></b>.</li>
- <li><b><a class="externalLink" href="https://issues.apache.org/jira/browse/PHOENIX-1177">Cost-based Query Optimization</a></b>. Enhance existing <a href="update_statistics.html">statistics collection</a> by enabling further query optmizations based on the size and cardinality of the data.
- <ul>
- <li><b><a class="externalLink" href="https://issues.apache.org/jira/browse/PHOENIX-1178">Generate histograms</a></b> to drive query optimization decisions such as secondary index usage and join ordering based on cardinalities to produce the most efficient query plan.</li>
- </ul></li>
- <li><b><a class="externalLink" href="https://issues.apache.org/jira/browse/PHOENIX-514">Functional Indexes</a></b>. Enables an index to contain the evaluation of an expression as opposed to just a column value and use the index when a statement contains this expression.</li>
<li><b>Type Enhancements</b>. Additional work includes support for <a class="externalLink" href="https://issues.apache.org/jira/browse/PHOENIX-476">DEFAULT declaration</a> when creating a table, and for <a class="externalLink" href="https://issues.apache.org/jira/browse/PHOENIX-477">STRUCT</a> and <a class="externalLink" href="https://issues.apache.org/jira/browse/PHOENIX-628">JSON</a> data types.</li>
- <li><b><a class="externalLink" href="https://issues.apache.org/jira/browse/PHOENIX-1121">Monitoring and Management Improvements</a></b>. Though we support <a href="tracing.html">tracing</a> now, thereâs more work to do to round out our monitoring and management capabilities.</li>
<li><b><a class="externalLink" href="https://issues.apache.org/jira/browse/PHOENIX-154">OLAP Extensions</a></b>. Support the <tt>WINDOW</tt>, <tt>PARTITION OVER</tt>, <tt>RANK</tt>, and other SQL-92 extensions.</li>
<li><b><a class="externalLink" href="https://issues.apache.org/jira/browse/PHOENIX-590">Multi-version Row Queries</a></b>. Expose the time dimension of rows through a built-in function to allow aggregation and trending over multiple row versions.</li>
<li><b><a class="externalLink" href="https://issues.apache.org/jira/browse/PHOENIX-153">Table Sampling</a></b>. Support the <tt>TABLESAMPLE</tt> clause by implementing a filter that uses the guideposts established by stats gathering to only return n rows per region.</li>
@@ -161,7 +160,6 @@
<li><b>Third Party Integration</b>. There are a number of open source projects with which interop with Phoenix could be added or improved:
<ul>
<li><b><a class="externalLink" href="https://issues.apache.org/jira/browse/PHOENIX-763">Apache Sqoop integration</a></b>. Enable Sqoop to import Phoenix-compliant HBase tables from relational databases.</li>
- <li><b><a class="externalLink" href="https://issues.apache.org/jira/browse/PHOENIX-687">Improve Map-reduce integration</a></b>. Itâs possible that we could provide a processing model where the map and reduce functions can invoke Phoenix queries (though this needs some more thought).</li>
<li><b>Apache Crunch integration</b>. Enable Apache Phoenix to easily be used as a more performant alternative in Apache Crunch to their HBase integration.</li>
<li><b>Apache BigTop example</b>. Add an example usage of Apache Phoenix with other Big Data tools as a conical example in Apache BigTop.</li>
</ul></li>
Modified: phoenix/site/publish/upgrading.html
URL: http://svn.apache.org/viewvc/phoenix/site/publish/upgrading.html?rev=1658880&r1=1658879&r2=1658880&view=diff
==============================================================================
--- phoenix/site/publish/upgrading.html (original)
+++ phoenix/site/publish/upgrading.html Wed Feb 11 06:04:04 2015
@@ -1,7 +1,7 @@
<!DOCTYPE html>
<!--
- Generated by Apache Maven Doxia at 2015-01-27
+ Generated by Apache Maven Doxia at 2015-02-10
Rendered using Reflow Maven Skin 1.1.0 (http://andriusvelykis.github.io/reflow-maven-skin)
-->
<html xml:lang="en" lang="en">
@@ -132,43 +132,24 @@
<div class="page-header">
<h1>Upgrading Phoenix</h1>
</div>
-<p>Phoenix uses a three number versioning schema of the form <major version>.<minor version>.<patch version>. For example, 4.2.1 has a major version of 4, a minor version of 2, and a patch version of 1.</p>
-<p>When upgrading to a new minor release (i.e. the major version is the same, but the minor version has changed), sometimes modifications to the system tables are necessary to either fix a bug or provide a new feature. This upgrade will occur automatically the first time a newly upgraded client connects to the newly upgraded server. It is expected that the server-side jar is upgraded first across your entire cluster, before any clients are upgraded. An older client will work with a newer server jar when the minor version is different, but not visa versa. In other words, clients do not need to be upgraded in lock step with the server. However, as of 4.2 and below, it is expected that all clients are upgraded at the same time (i.e. a mix of clients with different versions will not necessarily change). This may be improved in the future to allow a mix of old and new client versions (<a class="externalLink" href="https://issues.apache.org/jira/browse/PHOENIX-1483">PHOENIX-1483</a>).</p>
-<p>Upgrading to a new patch release may occur in any order: client first or server first, and a mix of clients with different patch release versions is fine.</p>
-<p>Upgrading to a new major release may require downtime as well as potentially the running of a migration script. This will be determined on a release by release basis.</p>
-<div class="section">
- <h2 id="Upgrading_from_Phoenix_2.2.x_to_3.04.0">Upgrading from Phoenix 2.2.x to 3.0/4.0</h2>
- <p>By default, Phoenix 2.2.x tables are not automatically upgraded to Apache Phoenix 3.0/4.0 tables. Since pre-Apache 2.2.x code lines have a different package structure (<tt>com.salesforce.phoenix</tt>) than the 3.0/4.0 code line (<tt>org.apache.phoenix</tt>), the two installations may actually coexist. An existing Phoenix table may either remain as a 2.2.x table or be upgraded to 3.0/4.0 table, but not both. In addition, a client JVM may either use the 3.0/4.0 driver or the 2.2.x driver, but not both. Upgrade, however, is a one way street: once a table is upgrade to 3.0/4.0, it stays that way.</p>
- <p>Note that upgrading a table will not affect its data - only the metadata of the table will change. In order to upgrade tables from 2.2.x to 3.0/4.0, the following must be done <b>BEFORE</b> the first connection to a cluster which has 3.0/4.0 installed on it. </p>
- <ul>
- <li> <p>Add a new <tt>phoenix.client.autoUpgradeWhiteList</tt> config parameter to your client-side hbase-sites.xml. Make sure the directory containing the hbase-sites.xml is on the classpath of your client so that HBase finds it. The value you use for the parameter depends on which tables you want to upgrade:</p>
- <ul>
- <li>To upgrade all tables use a value of *. This will cause all Phoenix 2.2.x tables to be automatically converted to the new 3.0.0 structure when the first connection occurs. For example:</li>
- </ul>
- <div class="source">
- <pre> <configuration>
- <property>
- <name>phoenix.client.autoUpgradeWhiteList</name>
- <value>*</value>
- </property>
- </configuration>
-</pre>
- </div>
- <ul>
- <li>To upgrade only some tables use a comma separated list of full table names. In that case, only those tables and their secondary indexes will be upgraded on first connection to a cluster. Note that table names are case sensitive. For example, the following would upgrade <tt>my_schema.my_table</tt> and <tt>MY_OTHER_TABLE</tt>:</li>
- </ul>
- <div class="source">
- <pre> <configuration>
- <property>
- <name>phoenix.client.autoUpgradeWhiteList</name>
- <value>my_schema.my_table,MY_OTHER_TABLE</value>
- </property>
- </configuration>
+<p>Phoenix uses a standard three number versioning schema of the form:</p>
+<div class="source">
+ <pre><major version> . <minor version> . <patch version>
</pre>
- </div></li>
- <li>After the first connection has been made to a cluster with Phoenix 3.0/4.0 installed, no further upgrade will take place. However, you may force it to take place again by removing the <tt>UpgradeTo30</tt> attribute from the <tt>SYSTEM.CATALOG</tt> HBase table metadata. Then, on the next connection to the cluster, upgrade will again occur as describe above.</li>
- <li>If youâve been using a pre-release Phoenix 3.0/4.0 SNAPSHOT jar, your metadata wonât be compatible with the released metadata schema. You should disable and drop your SYSTEM.CATALOG and SYSTEM.SEQUENCE tables from an HBase shell and re-run your DDL commands to re-create your Phoenix table. In addition, make sure the SNAPSHOT jar is removed from your HBase lib directory and client directories.</li>
- </ul>
+</div>
+<p>For example, <b><tt>4.2.1</tt></b> has a major version of <b><tt>4</tt></b>, a minor version of <b><tt>2</tt></b>, and a patch version of <b><tt>1</tt></b>.</p>
+<div class="section">
+ <h2 id="Patch_Release">Patch Release</h2>
+ <p>Upgrading to a new patch release (i.e. only the patch version has changed) is the simplest case. The jar upgrade may occur in any order: client first or server first, and a mix of clients with different patch release versions is fine.</p>
+</div>
+<div class="section">
+ <h2 id="Minor_Release">Minor Release</h2>
+ <p>When upgrading to a new minor release (i.e. the major version is the same, but the minor version has changed), sometimes modifications to the system tables are necessary to either fix a bug or provide a new feature. This upgrade will occur automatically the first time a newly upgraded client connects to the newly upgraded server. It is <b>required</b> that the server-side jar be upgraded first across your entire cluster, before any clients are upgraded. An older client will work with a newer server jar when the minor version is different, but not visa versa. In other words, clients do not need to be upgraded in lock step with the server.</p>
+ <p>As of the 4.3 release, a mix of clients on different minor release versions is supported (note that prior releases required all clients to be upgraded at the same time). Another improvement as of the 4.3 release is that an upgrade may be done directly from one minor version to any other higher minor version (prior releases required an upgrade to each minor version in between).</p>
+</div>
+<div class="section">
+ <h2 id="Major_Release">Major Release</h2>
+ <p>Upgrading to a new major release may require downtime as well as potentially the running of a migration script. Additionally, all clients and servers may need to be upgraded at the same time. This will be determined on a release by release basis.</p>
</div>
</div>
</div>
Modified: phoenix/site/source/src/site/markdown/recent.md
URL: http://svn.apache.org/viewvc/phoenix/site/source/src/site/markdown/recent.md?rev=1658880&r1=1658879&r2=1658880&view=diff
==============================================================================
--- phoenix/site/source/src/site/markdown/recent.md (original)
+++ phoenix/site/source/src/site/markdown/recent.md Wed Feb 11 06:04:04 2015
@@ -2,6 +2,8 @@
As items are implemented from our road map, they are moved here to track the progress we've made:
+1. **[Functional Indexes](secondary_indexing.html#Functional_Indexes)**. Enables an index to be defined as expressions as opposed to just column names and have the index be used when a query contains this expression.
+2. **[Map-reduce Integration](phoenix_mr.html)**. Support general map-reduce integration to Phoenix by implementing custom input and output formats.
1. **[Statistics Collection](update_statistics.html)**. Collects the statistics for a table to improve query parallelization. **Available in our 3.2/4.2 release**
2. **[Join Improvements](joins.html)**. Improve existing hash join implementation.
* **[Many-to-many joins](https://issues.apache.org/jira/browse/PHOENIX-1179)**. Support joins where both sides are too large to fit into memory. **Available in our 3.3/4.3 release**
Modified: phoenix/site/source/src/site/markdown/roadmap.md
URL: http://svn.apache.org/viewvc/phoenix/site/source/src/site/markdown/roadmap.md?rev=1658880&r1=1658879&r2=1658880&view=diff
==============================================================================
--- phoenix/site/source/src/site/markdown/roadmap.md (original)
+++ phoenix/site/source/src/site/markdown/roadmap.md Wed Feb 11 06:04:04 2015
@@ -3,15 +3,14 @@
Our roadmap is driven by our user community. Below, in prioritized order, is the current plan for Phoenix:
1. **[Transaction Support](https://issues.apache.org/jira/browse/PHOENIX-400)**. Support transactions by integrating with an open source solution like [Tephra](https://github.com/continuuity/tephra), [Themis](https://github.com/XiaoMi/themis), or some other similar option.
+10. **[Monitoring and Management Improvements](https://issues.apache.org/jira/browse/PHOENIX-1121)**. Though we support [tracing](tracing.html) now, there's more work to do to round out our monitoring and management capabilities.
+15. **[Cost-based Query Optimization]((https://issues.apache.org/jira/browse/PHOENIX-1177))**. Enhance existing [statistics collection](update_statistics.html) by enabling further query optmizations based on the size and cardinality of the data.
+ * **[Generate histograms](https://issues.apache.org/jira/browse/PHOENIX-1178)** to drive query optimization decisions such as secondary index usage and join ordering based on cardinalities to produce the most efficient query plan.
1. **[Join Improvements](https://issues.apache.org/jira/browse/PHOENIX-1167)**. Enhance our join capabilities in a variety of ways:<br/>
* **[Table-stats-guided choice between hash join and sort-merge join](https://issues.apache.org/jira/browse/PHOENIX-1556)**. Base hash join versus many-to-many decision on how many guideposts will be traversed for RHS table(s).
* **[Inlined parent/child joins](https://issues.apache.org/jira/browse/PHOENIX-150)**. Optimize parent/child joins by storing child rows inside of a parent row, forming the column qualifier through a known prefix plus the child row primary key.
2. **[Subquery](subqueries.html) Enhancement**, which includes support for **[correlated subqueries in the HAVING clause](https://issues.apache.org/jira/browse/PHOENIX-1388)** and **[using subqueries as expressions](https://issues.apache.org/jira/browse/PHOENIX-1392)**.
-15. **[Cost-based Query Optimization]((https://issues.apache.org/jira/browse/PHOENIX-1177))**. Enhance existing [statistics collection](update_statistics.html) by enabling further query optmizations based on the size and cardinality of the data.
- * **[Generate histograms](https://issues.apache.org/jira/browse/PHOENIX-1178)** to drive query optimization decisions such as secondary index usage and join ordering based on cardinalities to produce the most efficient query plan.
-9. **[Functional Indexes](https://issues.apache.org/jira/browse/PHOENIX-514)**. Enables an index to contain the evaluation of an expression as opposed to just a column value and use the index when a statement contains this expression.
6. **Type Enhancements**. Additional work includes support for [DEFAULT declaration](https://issues.apache.org/jira/browse/PHOENIX-476) when creating a table, and for [STRUCT](https://issues.apache.org/jira/browse/PHOENIX-477) and [JSON](https://issues.apache.org/jira/browse/PHOENIX-628) data types.
-10. **[Monitoring and Management Improvements](https://issues.apache.org/jira/browse/PHOENIX-1121)**. Though we support [tracing](tracing.html) now, there's more work to do to round out our monitoring and management capabilities.
17. **[OLAP Extensions](https://issues.apache.org/jira/browse/PHOENIX-154)**. Support the `WINDOW`, `PARTITION OVER`, `RANK`, and other SQL-92 extensions.
16. **[Multi-version Row Queries](https://issues.apache.org/jira/browse/PHOENIX-590)**. Expose the time dimension of rows through a built-in function to allow aggregation and trending over multiple row versions.
18. **[Table Sampling](https://issues.apache.org/jira/browse/PHOENIX-153)**. Support the <code>TABLESAMPLE</code> clause by implementing a filter that uses the guideposts established by stats gathering to only return n rows per region.
@@ -22,6 +21,5 @@ Our roadmap is driven by our user commun
19. **Schema Evolution**. Phoenix supports adding and removing columns through the [ALTER TABLE] (language/index.html#alter) DDL command, but changing the data type of, or renaming, an existing column is not yet supported.
7. **Third Party Integration**. There are a number of open source projects with which interop with Phoenix could be added or improved:
* **[Apache Sqoop integration](https://issues.apache.org/jira/browse/PHOENIX-763)**. Enable Sqoop to import Phoenix-compliant HBase tables from relational databases.
- * **[Improve Map-reduce integration](https://issues.apache.org/jira/browse/PHOENIX-687)**. It's possible that we could provide a processing model where the map and reduce functions can invoke Phoenix queries (though this needs some more thought).
* **Apache Crunch integration**. Enable Apache Phoenix to easily be used as a more performant alternative in Apache Crunch to their HBase integration.
* **Apache BigTop example**. Add an example usage of Apache Phoenix with other Big Data tools as a conical example in Apache BigTop.
Modified: phoenix/site/source/src/site/markdown/upgrading.md
URL: http://svn.apache.org/viewvc/phoenix/site/source/src/site/markdown/upgrading.md?rev=1658880&r1=1658879&r2=1658880&view=diff
==============================================================================
--- phoenix/site/source/src/site/markdown/upgrading.md (original)
+++ phoenix/site/source/src/site/markdown/upgrading.md Wed Feb 11 06:04:04 2015
@@ -1,35 +1,29 @@
#Upgrading Phoenix
-Phoenix uses a three number versioning schema of the form <major version>.<minor version>.<patch version>. For example, 4.2.1 has a major version of 4, a minor version of 2, and a patch version of 1.
+Phoenix uses a standard three number versioning schema of the form:
-When upgrading to a new minor release (i.e. the major version is the same, but the minor version has changed), sometimes modifications to the system tables are necessary to either fix a bug or provide a new feature. This upgrade will occur automatically the first time a newly upgraded client connects to the newly upgraded server. It is expected that the server-side jar is upgraded first across your entire cluster, before any clients are upgraded. An older client will work with a newer server jar when the minor version is different, but not visa versa. In other words, clients do not need to be upgraded in lock step with the server. However, as of 4.2 and below, it is expected that all clients are upgraded at the same time (i.e. a mix of clients with different versions will not necessarily change). This may be improved in the future to allow a mix of old and new client versions ([PHOENIX-1483](https://issues.apache.org/jira/browse/PHOENIX-1483)).
+ <major version> . <minor version> . <patch version>
-Upgrading to a new patch release may occur in any order: client first or server first, and a mix of clients with different patch release versions is fine.
+For example, **<code>4.2.1</code>** has a major version of **<code>4</code>**,
+a minor version of **<code>2</code>**, and a patch version of **<code>1</code>**.
-Upgrading to a new major release may require downtime as well as potentially the running of a migration script. This will be determined on a release by release basis.
+##Patch Release
+Upgrading to a new patch release (i.e. only the patch version has changed) is the simplest case. The jar upgrade may occur in any order: client first or server first, and a mix of clients with different patch release versions is fine.
+
+##Minor Release
+When upgrading to a new minor release (i.e. the major version is the same, but the minor
+version has changed), sometimes modifications to the system tables are necessary to either
+fix a bug or provide a new feature. This upgrade will occur automatically the first time a
+newly upgraded client connects to the newly upgraded server. It is **required** that the
+server-side jar be upgraded first across your entire cluster, before any clients are
+upgraded. An older client will work with a newer server jar when the minor version is
+different, but not visa versa. In other words, clients do not need to be upgraded in lock
+step with the server.
+
+As of the 4.3 release, a mix of clients on different
+minor release versions is supported (note that prior releases required all clients to be
+upgraded at the same time). Another improvement as of the 4.3 release is that an upgrade
+may be done directly from one minor version to any other higher minor version (prior releases required an upgrade to each minor version in between).
-##Upgrading from Phoenix 2.2.x to 3.0/4.0
-
-By default, Phoenix 2.2.x tables are not automatically upgraded to Apache Phoenix 3.0/4.0 tables. Since pre-Apache 2.2.x code lines have a different package structure (<code>com.salesforce.phoenix</code>) than the 3.0/4.0 code line (<code>org.apache.phoenix</code>), the two installations may actually coexist. An existing Phoenix table may either remain as a 2.2.x table or be upgraded to 3.0/4.0 table, but not both. In addition, a client JVM may either use the 3.0/4.0 driver or the 2.2.x driver, but not both. Upgrade, however, is a one way street: once a table is upgrade to 3.0/4.0, it stays that way.
-
-Note that upgrading a table will not affect its data - only the metadata of the table will change. In order to upgrade tables from 2.2.x to 3.0/4.0, the following must be done **BEFORE** the first connection to a cluster which has 3.0/4.0 installed on it.
-
-* Add a new <code>phoenix.client.autoUpgradeWhiteList</code> config parameter to your client-side hbase-sites.xml. Make sure the directory containing the hbase-sites.xml is on the classpath of your client so that HBase finds it. The value you use for the parameter depends on which tables you want to upgrade:
- * To upgrade all tables use a value of *. This will cause all Phoenix 2.2.x tables to be automatically converted to the new 3.0.0 structure when the first connection occurs. For example:
-
- <configuration>
- <property>
- <name>phoenix.client.autoUpgradeWhiteList</name>
- <value>*</value>
- </property>
- </configuration>
- * To upgrade only some tables use a comma separated list of full table names. In that case, only those tables and their secondary indexes will be upgraded on first connection to a cluster. Note that table names are case sensitive. For example, the following would upgrade <code>my_schema.my_table</code> and <code>MY_OTHER_TABLE</code>:
-
- <configuration>
- <property>
- <name>phoenix.client.autoUpgradeWhiteList</name>
- <value>my_schema.my_table,MY_OTHER_TABLE</value>
- </property>
- </configuration>
-* After the first connection has been made to a cluster with Phoenix 3.0/4.0 installed, no further upgrade will take place. However, you may force it to take place again by removing the <code>UpgradeTo30</code> attribute from the <code>SYSTEM.CATALOG</code> HBase table metadata. Then, on the next connection to the cluster, upgrade will again occur as describe above.
-* If you've been using a pre-release Phoenix 3.0/4.0 SNAPSHOT jar, your metadata won't be compatible with the released metadata schema. You should disable and drop your SYSTEM.CATALOG and SYSTEM.SEQUENCE tables from an HBase shell and re-run your DDL commands to re-create your Phoenix table. In addition, make sure the SNAPSHOT jar is removed from your HBase lib directory and client directories.
+##Major Release
+Upgrading to a new major release may require downtime as well as potentially the running of a migration script. Additionally, all clients and servers may need to be upgraded at the same time. This will be determined on a release by release basis.