[jira] [Reopened] (PHOENIX-788) Support cast from/to DATE/TIME/TIMESTAMP to/from LONG/UNSIGNED_LONG
[ https://issues.apache.org/jira/browse/PHOENIX-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor reopened PHOENIX-788: -- Assignee: James Taylor Support cast from/to DATE/TIME/TIMESTAMP to/from LONG/UNSIGNED_LONG --- Key: PHOENIX-788 URL: https://issues.apache.org/jira/browse/PHOENIX-788 Project: Phoenix Issue Type: Task Affects Versions: 3.0-Release Reporter: James Taylor Assignee: James Taylor Fix For: 3.0.0, 4.0.0, 5.0.0 We should support a manual cast between LONG and DATE/TIME/TIMESTAMP, for example: SELECT epoch_value CAST AS DATE FROM t; SELECT date CAST AS LONG FROM t; Requested by Tagged on the mailing list. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PHOENIX-788) Support cast from/to DATE/TIME/TIMESTAMP to/from LONG/UNSIGNED_LONG
[ https://issues.apache.org/jira/browse/PHOENIX-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14076677#comment-14076677 ] Hudson commented on PHOENIX-788: SUCCESS: Integrated in Phoenix | 3.0 | Hadoop1 #160 (See [https://builds.apache.org/job/Phoenix-3.0-hadoop1/160/]) PHOENIX-788 Support cast from/to DATE/TIME/TIMESTAMP to/from LONG/UNSIGNED_LONG (jtaylor: rev 9c85887af4d48a7bac45171ddd2a33fbd310a440) * phoenix-core/src/test/java/org/apache/phoenix/expression/RoundFloorCeilExpressionsUnitTests.java * phoenix-core/src/it/java/org/apache/phoenix/end2end/BaseQueryIT.java * phoenix-core/src/it/java/org/apache/phoenix/end2end/ClientTimeArithmeticQueryIT.java * phoenix-core/src/it/java/org/apache/phoenix/end2end/ScanQueryIT.java * phoenix-core/src/main/java/org/apache/phoenix/parse/FloorParseNode.java * phoenix-core/src/main/java/org/apache/phoenix/parse/CastParseNode.java * phoenix-core/src/main/java/org/apache/phoenix/parse/CeilParseNode.java * phoenix-core/src/it/java/org/apache/phoenix/end2end/GroupByIT.java * phoenix-core/src/main/java/org/apache/phoenix/expression/function/RoundDecimalExpression.java * phoenix-core/src/main/java/org/apache/phoenix/parse/RoundParseNode.java * phoenix-core/src/it/java/org/apache/phoenix/end2end/CastAndCoerceIT.java * phoenix-core/src/it/java/org/apache/phoenix/end2end/NotQueryIT.java * phoenix-core/src/main/java/org/apache/phoenix/expression/function/FloorDecimalExpression.java * phoenix-core/src/main/java/org/apache/phoenix/expression/function/CeilDecimalExpression.java * phoenix-core/src/it/java/org/apache/phoenix/end2end/CaseStatementIT.java * phoenix-core/src/it/java/org/apache/phoenix/end2end/QueryIT.java * phoenix-core/src/main/java/org/apache/phoenix/schema/PDataType.java Support cast from/to DATE/TIME/TIMESTAMP to/from LONG/UNSIGNED_LONG --- Key: PHOENIX-788 URL: https://issues.apache.org/jira/browse/PHOENIX-788 Project: Phoenix Issue Type: Task Affects Versions: 3.0-Release Reporter: James Taylor Assignee: James Taylor Fix For: 3.0.0, 4.0.0, 5.0.0 We should support a manual cast between LONG and DATE/TIME/TIMESTAMP, for example: SELECT CAST(epoch_value AS DATE) FROM t; SELECT CAST(date AS BIGINT) FROM t; Requested by Tagged on the mailing list. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (PHOENIX-788) Support cast from/to DATE/TIME/TIMESTAMP to/from LONG/UNSIGNED_LONG
[ https://issues.apache.org/jira/browse/PHOENIX-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor resolved PHOENIX-788. -- Resolution: Fixed Fix Version/s: (was: 4.0.0) (was: 3.0.0) 4.1 3.1 Support cast from/to DATE/TIME/TIMESTAMP to/from LONG/UNSIGNED_LONG --- Key: PHOENIX-788 URL: https://issues.apache.org/jira/browse/PHOENIX-788 Project: Phoenix Issue Type: Task Affects Versions: 3.0-Release Reporter: James Taylor Assignee: James Taylor Fix For: 5.0.0, 3.1, 4.1 We should support a manual cast between LONG and DATE/TIME/TIMESTAMP, for example: SELECT CAST(epoch_value AS DATE) FROM t; SELECT CAST(date AS BIGINT) FROM t; Requested by Tagged on the mailing list. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PHOENIX-788) Support cast from/to DATE/TIME/TIMESTAMP to/from LONG/UNSIGNED_LONG
[ https://issues.apache.org/jira/browse/PHOENIX-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14076698#comment-14076698 ] Hudson commented on PHOENIX-788: FAILURE: Integrated in Phoenix | Master | Hadoop1 #301 (See [https://builds.apache.org/job/Phoenix-master-hadoop1/301/]) PHOENIX-788 Support cast from/to DATE/TIME/TIMESTAMP to/from LONG/UNSIGNED_LONG (jtaylor: rev 72d4d5a680468f85fac22fa9ab69465c9feaebca) * phoenix-core/src/it/java/org/apache/phoenix/end2end/GroupByIT.java * phoenix-core/src/it/java/org/apache/phoenix/end2end/ScanQueryIT.java * phoenix-core/src/it/java/org/apache/phoenix/end2end/QueryIT.java * phoenix-core/src/it/java/org/apache/phoenix/end2end/BaseQueryIT.java * phoenix-core/src/main/java/org/apache/phoenix/parse/CastParseNode.java * phoenix-core/src/main/java/org/apache/phoenix/parse/RoundParseNode.java * phoenix-core/src/it/java/org/apache/phoenix/end2end/CastAndCoerceIT.java * phoenix-core/src/main/java/org/apache/phoenix/expression/function/RoundDecimalExpression.java * phoenix-core/src/test/java/org/apache/phoenix/expression/RoundFloorCeilExpressionsUnitTests.java * phoenix-core/src/main/java/org/apache/phoenix/schema/PDataType.java * phoenix-core/src/main/java/org/apache/phoenix/parse/FloorParseNode.java * phoenix-core/src/it/java/org/apache/phoenix/end2end/CaseStatementIT.java * phoenix-core/src/it/java/org/apache/phoenix/end2end/ClientTimeArithmeticQueryIT.java * phoenix-core/src/main/java/org/apache/phoenix/parse/CeilParseNode.java * phoenix-core/src/it/java/org/apache/phoenix/end2end/NotQueryIT.java * phoenix-core/src/main/java/org/apache/phoenix/expression/function/FloorDecimalExpression.java * phoenix-core/src/main/java/org/apache/phoenix/expression/function/CeilDecimalExpression.java Support cast from/to DATE/TIME/TIMESTAMP to/from LONG/UNSIGNED_LONG --- Key: PHOENIX-788 URL: https://issues.apache.org/jira/browse/PHOENIX-788 Project: Phoenix Issue Type: Task Affects Versions: 3.0-Release Reporter: James Taylor Assignee: James Taylor Fix For: 5.0.0, 3.1, 4.1 We should support a manual cast between LONG and DATE/TIME/TIMESTAMP, for example: SELECT CAST(epoch_value AS DATE) FROM t; SELECT CAST(date AS BIGINT) FROM t; Requested by Tagged on the mailing list. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PHOENIX-1016) Support MINVALUE, MAXVALUE, and CYCLE options in CREATE SEQUENCE
[ https://issues.apache.org/jira/browse/PHOENIX-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas D'Silva updated PHOENIX-1016: Attachment: PHOENIX-1016-master.v6.patch PHOENIX-1016-3.1.v6.patch Support MINVALUE, MAXVALUE, and CYCLE options in CREATE SEQUENCE Key: PHOENIX-1016 URL: https://issues.apache.org/jira/browse/PHOENIX-1016 Project: Phoenix Issue Type: Bug Reporter: James Taylor Assignee: Thomas D'Silva Fix For: 5.0.0, 3.1, 4.1 Attachments: AddSeqColumns.txt, PHOENIX-1016-3.1.v3.patch, PHOENIX-1016-3.1.v4.patch, PHOENIX-1016-3.1.v5.patch, PHOENIX-1016-3.1.v6.patch, PHOENIX-1016-4.1.v3.patch, PHOENIX-1016-4.1.v4.patch, PHOENIX-1016-master.v6.patch, PHOENIX-1016.3.0.patch, PHOENIX-1016.patch, PHOENIX-1016.v2.3.0.patch, PHOENIX-1016.v2.patch, PHOENIX-1016.v5.patch, diff.txt We currently don't support MINVALUE, MAXVALUE, and CYCLE options in CREATE SEQUENCE, but we should. See http://msdn.microsoft.com/en-us/library/ff878091.aspx for the syntax. I believe MINVALUE applies if the INCREMENT is negative while MAXVALUE applies otherwise. If the value of a sequence goes beyond MINVALUE/MAXVALUE, then: - if CYCLE is true, then the sequence value should start again at the START WITH value (or the MINVALUE if specified too? Not sure about this). - if CYCLE is false, then an exception should be thrown. To implement this: - make the grammar changes in PhoenixSQL.g - add member variables for MINVALUE, MAXVALUE, and CYCLE to CreateSequenceStatement - add the appropriate error checking and handle bind variables for these new options in CreateSequenceCompiler - modify the MetaDataClient.createSequence() call by passing along these new parameters. - same for ConnectionQueryServices.createSequence() call - same for Sequence.createSequence(). - pass along these parameters as new KeyValues in the Append that constitutes the RPC call - act on these in the SequenceRegionObserver coprocessor as indicated above. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (PHOENIX-1016) Support MINVALUE, MAXVALUE, and CYCLE options in CREATE SEQUENCE
[ https://issues.apache.org/jira/browse/PHOENIX-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas D'Silva reopened PHOENIX-1016: - [~jamestaylor], I have attached a patch that ensures that a 3.0/4.0 client can use sequences from a server that has been upgraded to 3.1/4.1 . I can detect if a client is using 3.0/4.0 or 3.1/4.1 based on the key values in the Increment and so I can preserve the 3.0/4.0 behavior. I changed the implementation to use CURRENT_VALUE stored in SYSTEM.SEQUENCE to represent the next available value, and this makes it simpler to preserve the previous behavior. I also added an @After annotation to SequenceIT to close the connection that was opened, so no connections are leaked. Thanks, Thomas Support MINVALUE, MAXVALUE, and CYCLE options in CREATE SEQUENCE Key: PHOENIX-1016 URL: https://issues.apache.org/jira/browse/PHOENIX-1016 Project: Phoenix Issue Type: Bug Reporter: James Taylor Assignee: Thomas D'Silva Fix For: 5.0.0, 3.1, 4.1 Attachments: AddSeqColumns.txt, PHOENIX-1016-3.1.v3.patch, PHOENIX-1016-3.1.v4.patch, PHOENIX-1016-3.1.v5.patch, PHOENIX-1016-4.1.v3.patch, PHOENIX-1016-4.1.v4.patch, PHOENIX-1016.3.0.patch, PHOENIX-1016.patch, PHOENIX-1016.v2.3.0.patch, PHOENIX-1016.v2.patch, PHOENIX-1016.v5.patch, diff.txt We currently don't support MINVALUE, MAXVALUE, and CYCLE options in CREATE SEQUENCE, but we should. See http://msdn.microsoft.com/en-us/library/ff878091.aspx for the syntax. I believe MINVALUE applies if the INCREMENT is negative while MAXVALUE applies otherwise. If the value of a sequence goes beyond MINVALUE/MAXVALUE, then: - if CYCLE is true, then the sequence value should start again at the START WITH value (or the MINVALUE if specified too? Not sure about this). - if CYCLE is false, then an exception should be thrown. To implement this: - make the grammar changes in PhoenixSQL.g - add member variables for MINVALUE, MAXVALUE, and CYCLE to CreateSequenceStatement - add the appropriate error checking and handle bind variables for these new options in CreateSequenceCompiler - modify the MetaDataClient.createSequence() call by passing along these new parameters. - same for ConnectionQueryServices.createSequence() call - same for Sequence.createSequence(). - pass along these parameters as new KeyValues in the Append that constitutes the RPC call - act on these in the SequenceRegionObserver coprocessor as indicated above. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PHOENIX-1112) Atomically rebuild index partially when index update fails
[
https://issues.apache.org/jira/browse/PHOENIX-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeffrey Zhong updated PHOENIX-1112:
---
Attachment: Phoenix-1112-v2.patch
[~giacomotaylor] I've incorporated your feedbacks into the v2 patch. In the V2
patch, I put antlr-runtime dependency into Phoenix-Core.jar while we could also
doc this and let users to drop antlr-runtime into HBase class path.
The pull request is at
https://github.com/jeffreyz88/phoenix-1/commit/897bf79243f1bbf03b6690add6a17dfd8fe41e2c
Atomically rebuild index partially when index update fails
Key: PHOENIX-1112
URL: https://issues.apache.org/jira/browse/PHOENIX-1112
Project: Phoenix
Issue Type: Sub-task
Reporter: Jeffrey Zhong
Assignee: Jeffrey Zhong
Attachments: Phoenix-1112-v2.patch, Phoenix-1112.patch
This is a short-term work around safe approach. Currently we disable an
index when index update failed(still possible bring down the whole cluster).
After an index is disable, human needs to be involved to rebuild entire index
which maybe not ideal.
The patch adds the support to automatically rebuild an disable index
partially from where it failed. In addition, it removes RS abort during WAL
recovery to prevent chain failures because we don't have to.
To disable automatically rebuilding failed index, add the following
configuration into hbase-site.xml:
{noformat}
property
namephoenix.index.failure.handling.rebuild/name
valuefalse/value
/property
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[GitHub] phoenix pull request: Phoenix-1112: Atomically rebuild index parti...
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/6#discussion_r15499838
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataProtocol.java
---
@@ -53,7 +53,7 @@
*/
public abstract class MetaDataProtocol extends MetaDataService {
public static final int PHOENIX_MAJOR_VERSION = 4;
-public static final int PHOENIX_MINOR_VERSION = 0;
+public static final int PHOENIX_MINOR_VERSION = 1;
--- End diff --
Please revert - I've already made this change.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] phoenix pull request: Phoenix-1112: Atomically rebuild index parti...
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/6#discussion_r15500164
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataRegionObserver.java
---
@@ -33,10 +64,15 @@
* to SYSTEM.TABLE.
*/
public class MetaDataRegionObserver extends BaseRegionObserver {
-
+public static final Log LOG =
LogFactory.getLog(MetaDataRegionObserver.class);
+protected Timer scheduleTimer = new Timer(true);
+private boolean enableRebuildIndex = true;
--- End diff --
Use the static constants you defined for these already in
QueryServicesOptions
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] phoenix pull request: Phoenix-1112: Atomically rebuild index parti...
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/6#discussion_r15500187
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataRegionObserver.java
---
@@ -54,5 +90,170 @@ public void start(CoprocessorEnvironment env) throws
IOException {
} catch (InterruptedException ie) {
Thread.currentThread().interrupt();
}
+ enableRebuildIndex =
env.getConfiguration().getBoolean(QueryServices.INDEX_FAILURE_HANDLING_REBUILD,
+QueryServicesOptions.DEFAULT_INDEX_FAILURE_HANDLING_REBUILD);
+ rebuildIndexTimeInterval =
env.getConfiguration().getLong(QueryServices.INDEX_FAILURE_HANDLING_REBUILD_INTERVAL,
+
QueryServicesOptions.DEFAULT_INDEX_FAILURE_HANDLING_REBUILD_INTERVAL);
+}
+
+
+@Override
+public void postOpen(ObserverContextRegionCoprocessorEnvironment e)
{
--- End diff --
Can you please follow the 4 space convention that's used everywhere else?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] phoenix pull request: Phoenix-1112: Atomically rebuild index parti...
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/6#discussion_r15500517
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/schema/MetaDataClient.java ---
@@ -513,6 +551,13 @@ private MutationState buildIndex(PTable index,
TableRef dataTableRef) throws SQL
// index maintainers.
// Define the LOCAL_INDEX_BUILD as a new static in
BaseScannerRegionObserver
Scan scan = plan.getContext().getScan();
+if(lowerBoundTimeStamp != null) {
+try {
+scan.setTimeRange(lowerBoundTimeStamp,
Long.MAX_VALUE);
--- End diff --
Shouldn't this match what's done below instead? Otherwise, when we do the
plan.iterator().next() below, it'll probably get overridden.
plan.getContext().setScanTimeRange(new TimeRange(lowerBoundTimeStamp,
Long.MAX_VALUE))
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] phoenix pull request: Phoenix-1112: Atomically rebuild index parti...
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/6#discussion_r15500727
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/schema/MetaDataClient.java ---
@@ -493,11 +514,28 @@ private MutationState buildIndexAtTimeStamp(PTable
index, NamedTableNode dataTab
}
private MutationState buildIndex(PTable index, TableRef dataTableRef)
throws SQLException {
+return buildIndex(index, dataTableRef, null);
+}
+
+private MutationState buildIndex(PTable index, TableRef dataTableRef,
+Long lowerBoundTimeStamp) throws SQLException {
+AlterIndexStatement indexStatement = null;
boolean wasAutoCommit = connection.getAutoCommit();
connection.rollback();
+boolean needRestoreIndexState = false;
try {
connection.setAutoCommit(true);
MutationState state;
+if(lowerBoundTimeStamp != null) {
--- End diff --
I think its better if this block of code lived in
buildPartialIndexFromTimeStamp, as it's not related to building the index.
Also, would you mind adding a comment about why you're setting the index from
DISABLED to INACTIVE? Is it so that incremental maintenance will start again
and data rows that are updated while the partial rebuild is occurring will get
added to the index (i.e. you won't miss any)?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] phoenix pull request: Phoenix-1112: Atomically rebuild index parti...
Github user JamesRTaylor commented on a diff in the pull request: https://github.com/apache/phoenix/pull/6#discussion_r15501061 --- Diff: phoenix-core/pom.xml --- @@ -168,9 +168,30 @@ plugin !--Make it so assembly:single does nothing in here -- artifactIdmaven-assembly-plugin/artifactId -configuration - skipAssemblytrue/skipAssembly -/configuration +executions --- End diff -- I'm torn on this one. I think this is probably easiest, as I wouldn't want to require two jars. Is there any value to having a phoenix jar with only phoenix stuff in it? I suppose not. If we go this route, we should get rid of the minimal-phoenix-client.jar, as this jar will match that one. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] phoenix pull request: Phoenix-1112: Atomically rebuild index parti...
Github user JamesRTaylor commented on a diff in the pull request: https://github.com/apache/phoenix/pull/6#discussion_r15501164 --- Diff: phoenix-core/src/main/java/org/apache/phoenix/query/QueryServices.java --- @@ -113,6 +113,17 @@ // The following config settings is to deal with SYSTEM.CATALOG moves(PHOENIX-916) among region servers public static final String CLOCK_SKEW_INTERVAL_ATTRIB = phoenix.clock.skew.interval; +// A master switch if to enable auto rebuild an index which failed to be updated previously +public static final String INDEX_FAILURE_HANDLING_REBUILD = phoenix.index.failure.handling.rebuild; --- End diff -- Add _ATTRIB to follow convention. Maybe INDEX_PARTIAL_REBUILD_ATTRIB? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] phoenix pull request: Phoenix-1112: Atomically rebuild index parti...
Github user JamesRTaylor commented on a diff in the pull request: https://github.com/apache/phoenix/pull/6#discussion_r15501192 --- Diff: phoenix-core/src/main/java/org/apache/phoenix/query/QueryServices.java --- @@ -113,6 +113,17 @@ // The following config settings is to deal with SYSTEM.CATALOG moves(PHOENIX-916) among region servers public static final String CLOCK_SKEW_INTERVAL_ATTRIB = phoenix.clock.skew.interval; +// A master switch if to enable auto rebuild an index which failed to be updated previously +public static final String INDEX_FAILURE_HANDLING_REBUILD = phoenix.index.failure.handling.rebuild; + +// Time interval to check if there is an index needs to be rebuild +public static final String INDEX_FAILURE_HANDLING_REBUILD_INTERVAL = --- End diff -- INDEX_PARTIAL_REBUILD_INTERVAL_ATTRIB? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PHOENIX-916) Time clock skew issue when SYSTEM.CATALOG moves between region servers
[ https://issues.apache.org/jira/browse/PHOENIX-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14077229#comment-14077229 ] ASF GitHub Bot commented on PHOENIX-916: Github user JamesRTaylor commented on a diff in the pull request: https://github.com/apache/phoenix/pull/6#discussion_r15501192 --- Diff: phoenix-core/src/main/java/org/apache/phoenix/query/QueryServices.java --- @@ -113,6 +113,17 @@ // The following config settings is to deal with SYSTEM.CATALOG moves(PHOENIX-916) among region servers public static final String CLOCK_SKEW_INTERVAL_ATTRIB = phoenix.clock.skew.interval; +// A master switch if to enable auto rebuild an index which failed to be updated previously +public static final String INDEX_FAILURE_HANDLING_REBUILD = phoenix.index.failure.handling.rebuild; + +// Time interval to check if there is an index needs to be rebuild +public static final String INDEX_FAILURE_HANDLING_REBUILD_INTERVAL = --- End diff -- INDEX_PARTIAL_REBUILD_INTERVAL_ATTRIB? Time clock skew issue when SYSTEM.CATALOG moves between region servers -- Key: PHOENIX-916 URL: https://issues.apache.org/jira/browse/PHOENIX-916 Project: Phoenix Issue Type: Bug Affects Versions: 3.0.0, 4.0.0, 5.0.0 Reporter: Jeffrey Zhong Assignee: Jeffrey Zhong Priority: Critical Fix For: 5.0.0, 3.1, 4.1 Attachments: phoenix-916-v2.patch, phoenix-916-v3.patch, phoenix-916.patch Since we rely on the sever time stamp of RS which is hosting SYSTEM.CATALOG. When the table moves to another region server, the server time may decrease(increasing is all right). This may cause a query doesn't return anything though it should be. -- This message was sent by Atlassian JIRA (v6.2#6252)
[GitHub] phoenix pull request: Phoenix-1112: Atomically rebuild index parti...
Github user JamesRTaylor commented on the pull request: https://github.com/apache/phoenix/pull/6#issuecomment-50422772 Looking very good, @jeffreyz88. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PHOENIX-1016) Support MINVALUE, MAXVALUE, and CYCLE options in CREATE SEQUENCE
[ https://issues.apache.org/jira/browse/PHOENIX-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14077318#comment-14077318 ] Hudson commented on PHOENIX-1016: - FAILURE: Integrated in Phoenix | 3.0 | Hadoop1 #164 (See [https://builds.apache.org/job/Phoenix-3.0-hadoop1/164/]) PHOENIX-1016 Support MINVALUE, MAXVALUE, and CYCLE options in CREATE SEQUENCE (Thomas D'Silva) (jtaylor: rev 7cc2b5a54e98b7db990c2b81bcc269c49509ce26) * phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataProtocol.java * phoenix-core/src/main/java/org/apache/phoenix/iterate/SkipRangeParallelIteratorRegionSplitter.java * phoenix-core/src/main/java/org/apache/phoenix/jdbc/PhoenixDatabaseMetaData.java * phoenix-core/src/test/java/org/apache/phoenix/util/SequenceUtilTest.java * phoenix-core/src/main/java/org/apache/phoenix/util/SequenceUtil.java * phoenix-core/src/main/java/org/apache/phoenix/coprocessor/SequenceRegionObserver.java * phoenix-core/src/main/java/org/apache/phoenix/util/KeyValueUtil.java * phoenix-core/src/main/java/org/apache/phoenix/schema/SequenceInfo.java * phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java * phoenix-core/src/main/java/org/apache/phoenix/query/QueryConstants.java * phoenix-core/src/it/java/org/apache/phoenix/end2end/SequenceIT.java * phoenix-core/src/main/java/org/apache/phoenix/schema/Sequence.java * phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionlessQueryServicesImpl.java Support MINVALUE, MAXVALUE, and CYCLE options in CREATE SEQUENCE Key: PHOENIX-1016 URL: https://issues.apache.org/jira/browse/PHOENIX-1016 Project: Phoenix Issue Type: Bug Reporter: James Taylor Assignee: Thomas D'Silva Fix For: 5.0.0, 3.1, 4.1 Attachments: AddSeqColumns.txt, PHOENIX-1016-3.1.v3.patch, PHOENIX-1016-3.1.v4.patch, PHOENIX-1016-3.1.v5.patch, PHOENIX-1016-3.1.v6.patch, PHOENIX-1016-4.1.v3.patch, PHOENIX-1016-4.1.v4.patch, PHOENIX-1016-master.v6.patch, PHOENIX-1016.3.0.patch, PHOENIX-1016.patch, PHOENIX-1016.v2.3.0.patch, PHOENIX-1016.v2.patch, PHOENIX-1016.v5.patch, diff.txt We currently don't support MINVALUE, MAXVALUE, and CYCLE options in CREATE SEQUENCE, but we should. See http://msdn.microsoft.com/en-us/library/ff878091.aspx for the syntax. I believe MINVALUE applies if the INCREMENT is negative while MAXVALUE applies otherwise. If the value of a sequence goes beyond MINVALUE/MAXVALUE, then: - if CYCLE is true, then the sequence value should start again at the START WITH value (or the MINVALUE if specified too? Not sure about this). - if CYCLE is false, then an exception should be thrown. To implement this: - make the grammar changes in PhoenixSQL.g - add member variables for MINVALUE, MAXVALUE, and CYCLE to CreateSequenceStatement - add the appropriate error checking and handle bind variables for these new options in CreateSequenceCompiler - modify the MetaDataClient.createSequence() call by passing along these new parameters. - same for ConnectionQueryServices.createSequence() call - same for Sequence.createSequence(). - pass along these parameters as new KeyValues in the Append that constitutes the RPC call - act on these in the SequenceRegionObserver coprocessor as indicated above. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (PHOENIX-1016) Support MINVALUE, MAXVALUE, and CYCLE options in CREATE SEQUENCE
[ https://issues.apache.org/jira/browse/PHOENIX-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor resolved PHOENIX-1016. --- Resolution: Fixed Support MINVALUE, MAXVALUE, and CYCLE options in CREATE SEQUENCE Key: PHOENIX-1016 URL: https://issues.apache.org/jira/browse/PHOENIX-1016 Project: Phoenix Issue Type: Bug Reporter: James Taylor Assignee: Thomas D'Silva Fix For: 5.0.0, 3.1, 4.1 Attachments: AddSeqColumns.txt, PHOENIX-1016-3.1.v3.patch, PHOENIX-1016-3.1.v4.patch, PHOENIX-1016-3.1.v5.patch, PHOENIX-1016-3.1.v6.patch, PHOENIX-1016-4.1.v3.patch, PHOENIX-1016-4.1.v4.patch, PHOENIX-1016-master.v6.patch, PHOENIX-1016.3.0.patch, PHOENIX-1016.patch, PHOENIX-1016.v2.3.0.patch, PHOENIX-1016.v2.patch, PHOENIX-1016.v5.patch, diff.txt We currently don't support MINVALUE, MAXVALUE, and CYCLE options in CREATE SEQUENCE, but we should. See http://msdn.microsoft.com/en-us/library/ff878091.aspx for the syntax. I believe MINVALUE applies if the INCREMENT is negative while MAXVALUE applies otherwise. If the value of a sequence goes beyond MINVALUE/MAXVALUE, then: - if CYCLE is true, then the sequence value should start again at the START WITH value (or the MINVALUE if specified too? Not sure about this). - if CYCLE is false, then an exception should be thrown. To implement this: - make the grammar changes in PhoenixSQL.g - add member variables for MINVALUE, MAXVALUE, and CYCLE to CreateSequenceStatement - add the appropriate error checking and handle bind variables for these new options in CreateSequenceCompiler - modify the MetaDataClient.createSequence() call by passing along these new parameters. - same for ConnectionQueryServices.createSequence() call - same for Sequence.createSequence(). - pass along these parameters as new KeyValues in the Append that constitutes the RPC call - act on these in the SequenceRegionObserver coprocessor as indicated above. -- This message was sent by Atlassian JIRA (v6.2#6252)
