[jira] [Commented] (PHOENIX-1077) Exception thrown when executing an IN list of Row Value Constructors against salted tables.
[
https://issues.apache.org/jira/browse/PHOENIX-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059682#comment-14059682
]
Hudson commented on PHOENIX-1077:
-
SUCCESS: Integrated in Phoenix | 3.0 | Hadoop1 #133 (See
[https://builds.apache.org/job/Phoenix-3.0-hadoop1/133/])
Fix for PHOENIX-1077 in 3.0 branch (fixed by Kyle Buzsaki) (elilevine: rev
fd4a1a5d05861d8e5e7c153cecc480e9ff8b0229)
* phoenix-core/src/main/java/org/apache/phoenix/schema/ValueSchema.java
* phoenix-core/src/main/java/org/apache/phoenix/schema/SaltingUtil.java
* phoenix-core/src/it/java/org/apache/phoenix/end2end/RowValueConstructorIT.java
Exception thrown when executing an IN list of Row Value Constructors against
salted tables.
---
Key: PHOENIX-1077
URL: https://issues.apache.org/jira/browse/PHOENIX-1077
Project: Phoenix
Issue Type: Bug
Affects Versions: 3.0.0, 4.0.0, 5.0.0
Reporter: Samarth Jain
Assignee: Kyle Buzsaki
Attachments: PHOENIX-1077.patch
{code}
1) Table - Salted. Query - IN list of RVCs. Result - fails with exception.
Details:
Table DDL - CREATE TABLE t (pk1 varchar(5) NOT NULL, pk2 varchar(5) NOT NULL,
pk3 INTEGER NOT NULL, c1 INTEGER constraint pk primary key (pk1,pk2,pk3))
SALT_BUCKETS=4
Query - select pk1, pk2, pk3 from t WHERE (pk1, pk2, pk3) IN ((?, ?, ?), (?,
?, ?))
Exception:
java.lang.ArrayIndexOutOfBoundsException: 1
at org.apache.phoenix.schema.ValueSchema.getField(ValueSchema.java:300)
at org.apache.phoenix.util.ScanUtil.setKey(ScanUtil.java:260)
at
org.apache.phoenix.compile.ScanRanges.getPointKeys(ScanRanges.java:185)
at org.apache.phoenix.compile.ScanRanges.create(ScanRanges.java:61)
at
org.apache.phoenix.compile.WhereOptimizer.pushKeyExpressionsToScan(WhereOptimizer.java:224)
at
org.apache.phoenix.compile.WhereCompiler.compile(WhereCompiler.java:105)
at
org.apache.phoenix.compile.QueryCompiler.compileSingleQuery(QueryCompiler.java:260)
at
org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:128)
at
org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:264)
at
org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:1)
at
org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:199)
at
org.apache.phoenix.jdbc.PhoenixPreparedStatement.executeQuery(PhoenixPreparedStatement.java:157)
at
org.apache.phoenix.end2end.RowValueConstructorIT.testInListOfRVC5(RowValueConstructorIT.java:1078)
2) Most likely related to 1) Table - multi-tenant and salted. Query - IN
list of RVCs. Result - Fails with exception.
Details:
Base Table DDL - CREATE TABLE t (tenantId varchar(5) NOT NULL, pk2 varchar(5)
NOT NULL, pk3 INTEGER NOT NULL, c1 INTEGER constraint pk primary key
(tenantId,pk2,pk3)) SALT_BUCKETS=4, MULTI_TENANT=true
Tenant View DDL - CREATE VIEW t_view (tenant_col VARCHAR) AS SELECT * FROM t
Query using global connection : select pk2, pk3 from t WHERE (tenantId, pk2,
pk3) IN ((?, ?, ?), (?, ?, ?))
Stacktrace:
java.lang.ArrayIndexOutOfBoundsException: 1
at org.apache.phoenix.schema.ValueSchema.getField(ValueSchema.java:300)
at org.apache.phoenix.util.ScanUtil.setKey(ScanUtil.java:260)
at
org.apache.phoenix.compile.ScanRanges.getPointKeys(ScanRanges.java:185)
at org.apache.phoenix.compile.ScanRanges.create(ScanRanges.java:61)
at
org.apache.phoenix.compile.WhereOptimizer.pushKeyExpressionsToScan(WhereOptimizer.java:224)
at
org.apache.phoenix.compile.WhereCompiler.compile(WhereCompiler.java:105)
at
org.apache.phoenix.compile.QueryCompiler.compileSingleQuery(QueryCompiler.java:260)
at
org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:128)
at
org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:264)
at
org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:1)
at
org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:199)
at
org.apache.phoenix.jdbc.PhoenixPreparedStatement.executeQuery(PhoenixPreparedStatement.java:157)
at
org.apache.phoenix.end2end.RowValueConstructorIT.testInListOfRVC4(RowValueConstructorIT.java:1042)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[GitHub] phoenix pull request: PHOENIX-933 Local index support to Phoenix
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/1#discussion_r14852114
--- Diff:
phoenix-core/src/it/java/org/apache/phoenix/end2end/BaseTenantSpecificViewIndexIT.java
---
@@ -117,26 +139,38 @@ private Connection createTenantConnection(String
tenantId) throws SQLException {
private void verifyViewData(Connection conn, String valuePrefix)
throws SQLException {
String query = SELECT k1, k2, v2 FROM v WHERE v2=' + valuePrefix
+ v2-1';
ResultSet rs = conn.createStatement().executeQuery(query);
-assertTrue(rs.next());
-assertEquals(1, rs.getInt(1));
-assertEquals(1, rs.getInt(2));
-assertEquals(valuePrefix + v2-1, rs.getString(3));
-assertTrue(rs.next());
-assertEquals(1, rs.getInt(1));
-assertEquals(3, rs.getInt(2));
-assertEquals(valuePrefix + v2-1, rs.getString(3));
-assertTrue(rs.next());
-assertEquals(1, rs.getInt(1));
-assertEquals(5, rs.getInt(2));
-assertEquals(valuePrefix + v2-1, rs.getString(3));
-assertTrue(rs.next());
-assertEquals(1, rs.getInt(1));
-assertEquals(7, rs.getInt(2));
-assertEquals(valuePrefix + v2-1, rs.getString(3));
-assertTrue(rs.next());
-assertEquals(1, rs.getInt(1));
-assertEquals(9, rs.getInt(2));
-assertEquals(valuePrefix + v2-1, rs.getString(3));
+ListListObject expectedResultsA = Lists.newArrayList(
+Arrays.ObjectasList(1,1, valuePrefix + v2-1),
+Arrays.ObjectasList(1,3, valuePrefix + v2-1),
+Arrays.ObjectasList(1,5, valuePrefix + v2-1),
+Arrays.ObjectasList(1,7, valuePrefix + v2-1),
+Arrays.ObjectasList(1,9, valuePrefix + v2-1));
+assertValuesEqualsResultSet(rs,expectedResultsA);
assertFalse(rs.next());
}
+
--- End diff --
This code looks familiar. If it matches original (I think from QueryIT),
can you move it into the base test class instead of copy/paste?
---
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-933 Local index support to Phoenix
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/1#discussion_r14852129
--- Diff:
phoenix-core/src/it/java/org/apache/phoenix/end2end/index/MutableIndexIT.java
---
@@ -51,21 +51,38 @@ public static void doSetup() throws Exception {
props.put(QueryServices.MAX_INTRA_REGION_PARALLELIZATION_ATTRIB,
Integer.toString(1));
// Forces server cache to be used
props.put(QueryServices.INDEX_MUTATE_BATCH_SIZE_THRESHOLD_ATTRIB,
Integer.toString(2));
+props.put(QueryServices.DROP_METADATA_ATTRIB,
Boolean.toString(true));
// Must update config before starting server
startServer(getUrl(), new
ReadOnlyProps(props.entrySet().iterator()));
}
-
+
@Test
public void testIndexWithNullableFixedWithCols() throws Exception {
+testIndexWithNullableFixedWithCols(false);
+}
+
+@Test
+public void testLocalIndexWithNullableFixedWithCols() throws Exception
{
+testIndexWithNullableFixedWithCols(true);
+}
+
+private void testIndexWithNullableFixedWithCols(boolean localIndex)
throws Exception {
Properties props = new Properties(TEST_PROPERTIES);
Connection conn = DriverManager.getConnection(getUrl(), props);
conn.setAutoCommit(false);
try {
createTestTable();
populateTestTable();
-String ddl = CREATE INDEX + INDEX_TABLE_NAME + ON +
DATA_TABLE_FULL_NAME
-+ (char_col1 ASC, int_col1 ASC)
-+ INCLUDE (long_col1, long_col2);
+String ddl = null;
+if(localIndex){
+ddl = CREATE INDEX + INDEX_TABLE_NAME + ON +
DATA_TABLE_FULL_NAME
--- End diff --
Looks like the if and the else branch match. If that's expected/correct,
can you get rid of the if statement?
---
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-933) Local index support to Phoenix
[
https://issues.apache.org/jira/browse/PHOENIX-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059703#comment-14059703
]
ASF GitHub Bot commented on PHOENIX-933:
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/1#discussion_r14852129
--- Diff:
phoenix-core/src/it/java/org/apache/phoenix/end2end/index/MutableIndexIT.java
---
@@ -51,21 +51,38 @@ public static void doSetup() throws Exception {
props.put(QueryServices.MAX_INTRA_REGION_PARALLELIZATION_ATTRIB,
Integer.toString(1));
// Forces server cache to be used
props.put(QueryServices.INDEX_MUTATE_BATCH_SIZE_THRESHOLD_ATTRIB,
Integer.toString(2));
+props.put(QueryServices.DROP_METADATA_ATTRIB,
Boolean.toString(true));
// Must update config before starting server
startServer(getUrl(), new
ReadOnlyProps(props.entrySet().iterator()));
}
-
+
@Test
public void testIndexWithNullableFixedWithCols() throws Exception {
+testIndexWithNullableFixedWithCols(false);
+}
+
+@Test
+public void testLocalIndexWithNullableFixedWithCols() throws Exception
{
+testIndexWithNullableFixedWithCols(true);
+}
+
+private void testIndexWithNullableFixedWithCols(boolean localIndex)
throws Exception {
Properties props = new Properties(TEST_PROPERTIES);
Connection conn = DriverManager.getConnection(getUrl(), props);
conn.setAutoCommit(false);
try {
createTestTable();
populateTestTable();
-String ddl = CREATE INDEX + INDEX_TABLE_NAME + ON +
DATA_TABLE_FULL_NAME
-+ (char_col1 ASC, int_col1 ASC)
-+ INCLUDE (long_col1, long_col2);
+String ddl = null;
+if(localIndex){
+ddl = CREATE INDEX + INDEX_TABLE_NAME + ON +
DATA_TABLE_FULL_NAME
--- End diff --
Looks like the if and the else branch match. If that's expected/correct,
can you get rid of the if statement?
Local index support to Phoenix
--
Key: PHOENIX-933
URL: https://issues.apache.org/jira/browse/PHOENIX-933
Project: Phoenix
Issue Type: New Feature
Reporter: rajeshbabu
Hindex(https://github.com/Huawei-Hadoop/hindex) provides local indexing
support to HBase. It stores region level index in a separate table, and
co-locates the user and index table regions with a custom load balancer.
See http://goo.gl/phkhwC and http://goo.gl/EswlxC for more information.
This JIRA addresses the local indexing solution integration to phoenix.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[GitHub] phoenix pull request: PHOENIX-933 Local index support to Phoenix
Github user chrajeshbabu commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/1#discussion_r14853783
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/ScanRegionObserver.java
---
@@ -100,7 +109,7 @@ public static void serializeIntoScan(Scan scan, int
thresholdBytes, int limit, L
}
}
-public static OrderedResultIterator deserializeFromScan(Scan scan,
RegionScanner s) {
+public static OrderedResultIterator deserializeFromScan(Scan scan,
RegionScanner s, int offset) {
--- End diff --
bq. There's a bit more you need to do to handle ORDER BY correctly. It'd be
for the case in which a data column was referenced in the ORDER BY while the
index table is being used to satisfy the query.
This is working fine James. I have added test case.
---
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-933) Local index support to Phoenix
[
https://issues.apache.org/jira/browse/PHOENIX-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059826#comment-14059826
]
ASF GitHub Bot commented on PHOENIX-933:
Github user chrajeshbabu commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/1#discussion_r14853783
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/ScanRegionObserver.java
---
@@ -100,7 +109,7 @@ public static void serializeIntoScan(Scan scan, int
thresholdBytes, int limit, L
}
}
-public static OrderedResultIterator deserializeFromScan(Scan scan,
RegionScanner s) {
+public static OrderedResultIterator deserializeFromScan(Scan scan,
RegionScanner s, int offset) {
--- End diff --
bq. There's a bit more you need to do to handle ORDER BY correctly. It'd be
for the case in which a data column was referenced in the ORDER BY while the
index table is being used to satisfy the query.
This is working fine James. I have added test case.
Local index support to Phoenix
--
Key: PHOENIX-933
URL: https://issues.apache.org/jira/browse/PHOENIX-933
Project: Phoenix
Issue Type: New Feature
Reporter: rajeshbabu
Hindex(https://github.com/Huawei-Hadoop/hindex) provides local indexing
support to HBase. It stores region level index in a separate table, and
co-locates the user and index table regions with a custom load balancer.
See http://goo.gl/phkhwC and http://goo.gl/EswlxC for more information.
This JIRA addresses the local indexing solution integration to phoenix.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (PHOENIX-933) Local index support to Phoenix
[
https://issues.apache.org/jira/browse/PHOENIX-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059828#comment-14059828
]
ASF GitHub Bot commented on PHOENIX-933:
Github user chrajeshbabu commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/1#discussion_r14853806
--- Diff:
phoenix-core/src/it/java/org/apache/phoenix/end2end/index/MutableIndexIT.java
---
@@ -51,21 +51,38 @@ public static void doSetup() throws Exception {
props.put(QueryServices.MAX_INTRA_REGION_PARALLELIZATION_ATTRIB,
Integer.toString(1));
// Forces server cache to be used
props.put(QueryServices.INDEX_MUTATE_BATCH_SIZE_THRESHOLD_ATTRIB,
Integer.toString(2));
+props.put(QueryServices.DROP_METADATA_ATTRIB,
Boolean.toString(true));
// Must update config before starting server
startServer(getUrl(), new
ReadOnlyProps(props.entrySet().iterator()));
}
-
+
@Test
public void testIndexWithNullableFixedWithCols() throws Exception {
+testIndexWithNullableFixedWithCols(false);
+}
+
+@Test
+public void testLocalIndexWithNullableFixedWithCols() throws Exception
{
+testIndexWithNullableFixedWithCols(true);
+}
+
+private void testIndexWithNullableFixedWithCols(boolean localIndex)
throws Exception {
Properties props = new Properties(TEST_PROPERTIES);
Connection conn = DriverManager.getConnection(getUrl(), props);
conn.setAutoCommit(false);
try {
createTestTable();
populateTestTable();
-String ddl = CREATE INDEX + INDEX_TABLE_NAME + ON +
DATA_TABLE_FULL_NAME
-+ (char_col1 ASC, int_col1 ASC)
-+ INCLUDE (long_col1, long_col2);
+String ddl = null;
+if(localIndex){
+ddl = CREATE INDEX + INDEX_TABLE_NAME + ON +
DATA_TABLE_FULL_NAME
--- End diff --
This is the actual code. Earlier by mistake I missed to add LOCAL in if
branch so if else branches are same.
if (localIndex) {
ddl = CREATE LOCAL INDEX + INDEX_TABLE_NAME + ON +
DATA_TABLE_FULL_NAME + (date_col);
} else {
ddl = CREATE INDEX + INDEX_TABLE_NAME + ON +
DATA_TABLE_FULL_NAME + (date_col);
}
Now I have corrected it.
Local index support to Phoenix
--
Key: PHOENIX-933
URL: https://issues.apache.org/jira/browse/PHOENIX-933
Project: Phoenix
Issue Type: New Feature
Reporter: rajeshbabu
Hindex(https://github.com/Huawei-Hadoop/hindex) provides local indexing
support to HBase. It stores region level index in a separate table, and
co-locates the user and index table regions with a custom load balancer.
See http://goo.gl/phkhwC and http://goo.gl/EswlxC for more information.
This JIRA addresses the local indexing solution integration to phoenix.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[GitHub] phoenix pull request: PHOENIX-933 Local index support to Phoenix
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/1#discussion_r14854253
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/ScanRegionObserver.java
---
@@ -100,7 +109,7 @@ public static void serializeIntoScan(Scan scan, int
thresholdBytes, int limit, L
}
}
-public static OrderedResultIterator deserializeFromScan(Scan scan,
RegionScanner s) {
+public static OrderedResultIterator deserializeFromScan(Scan scan,
RegionScanner s, int offset) {
--- End diff --
Excellent. Would you mind updating this pull request? I think it's ready to
get committed, no?
---
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-933) Local index support to Phoenix
[
https://issues.apache.org/jira/browse/PHOENIX-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059852#comment-14059852
]
ASF GitHub Bot commented on PHOENIX-933:
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/1#discussion_r14854253
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/ScanRegionObserver.java
---
@@ -100,7 +109,7 @@ public static void serializeIntoScan(Scan scan, int
thresholdBytes, int limit, L
}
}
-public static OrderedResultIterator deserializeFromScan(Scan scan,
RegionScanner s) {
+public static OrderedResultIterator deserializeFromScan(Scan scan,
RegionScanner s, int offset) {
--- End diff --
Excellent. Would you mind updating this pull request? I think it's ready to
get committed, no?
Local index support to Phoenix
--
Key: PHOENIX-933
URL: https://issues.apache.org/jira/browse/PHOENIX-933
Project: Phoenix
Issue Type: New Feature
Reporter: rajeshbabu
Hindex(https://github.com/Huawei-Hadoop/hindex) provides local indexing
support to HBase. It stores region level index in a separate table, and
co-locates the user and index table regions with a custom load balancer.
See http://goo.gl/phkhwC and http://goo.gl/EswlxC for more information.
This JIRA addresses the local indexing solution integration to phoenix.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (PHOENIX-933) Local index support to Phoenix
[
https://issues.apache.org/jira/browse/PHOENIX-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059899#comment-14059899
]
ASF GitHub Bot commented on PHOENIX-933:
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/1#discussion_r14855032
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/iterate/SkipRangeParallelIteratorRegionSplitter.java
---
@@ -54,7 +55,8 @@ protected
SkipRangeParallelIteratorRegionSplitter(StatementContext context, Tabl
public ListHRegionLocation filterRegions(ListHRegionLocation
allTableRegions, final ScanRanges ranges) {
IterableHRegionLocation regions;
-if (ranges == ScanRanges.EVERYTHING) {
+if (ranges == ScanRanges.EVERYTHING
--- End diff --
This shouldn't be necessary and will cause the skip scan not to be used
(which will be horrible for point queries). It should work fine to do the skip
scan for each region (much better than doing a full region scan for every
region).
Can you remove it and add a test that does a point lookup with multiple
values (for example, a IN clause with multiple values for an indexed column)?
Local index support to Phoenix
--
Key: PHOENIX-933
URL: https://issues.apache.org/jira/browse/PHOENIX-933
Project: Phoenix
Issue Type: New Feature
Reporter: rajeshbabu
Hindex(https://github.com/Huawei-Hadoop/hindex) provides local indexing
support to HBase. It stores region level index in a separate table, and
co-locates the user and index table regions with a custom load balancer.
See http://goo.gl/phkhwC and http://goo.gl/EswlxC for more information.
This JIRA addresses the local indexing solution integration to phoenix.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (PHOENIX-933) Local index support to Phoenix
[
https://issues.apache.org/jira/browse/PHOENIX-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14059948#comment-14059948
]
ASF GitHub Bot commented on PHOENIX-933:
Github user JamesRTaylor commented on the pull request:
https://github.com/apache/phoenix/pull/1#issuecomment-48825943
Related to the revert of the ScanRanges change, you'll need to make this
change to prevent the SkipRangeParallelIteratorRegionSplitter from being used
(as you always need to scan all regions for a local index). Cleanest might be
to just implement a simple ParallelIteratorRegionSplitter for use when a local
index is used that just returns all regions:
public class ParallelIteratorRegionSplitterFactory {
public static ParallelIteratorRegionSplitter
getSplitter(StatementContext context, TableRef table, HintNode hintNode) throws
SQLException {
if (!isLocalIndex
context.getScanRanges().useSkipScanFilter()) {
return
SkipRangeParallelIteratorRegionSplitter.getInstance(context, table, hintNode);
}
return
DefaultParallelIteratorRegionSplitter.getInstance(context, table, hintNode);
}
}
Local index support to Phoenix
--
Key: PHOENIX-933
URL: https://issues.apache.org/jira/browse/PHOENIX-933
Project: Phoenix
Issue Type: New Feature
Reporter: rajeshbabu
Hindex(https://github.com/Huawei-Hadoop/hindex) provides local indexing
support to HBase. It stores region level index in a separate table, and
co-locates the user and index table regions with a custom load balancer.
See http://goo.gl/phkhwC and http://goo.gl/EswlxC for more information.
This JIRA addresses the local indexing solution integration to phoenix.
--
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: diff.txt 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 Attachments: PHOENIX-1016.3.0.patch, PHOENIX-1016.patch, PHOENIX-1016.v2.3.0.patch, PHOENIX-1016.v2.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-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: (was: diff.txt) 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 Attachments: PHOENIX-1016.3.0.patch, PHOENIX-1016.patch, PHOENIX-1016.v2.3.0.patch, PHOENIX-1016.v2.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-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: diff.txt 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 Attachments: PHOENIX-1016.3.0.patch, PHOENIX-1016.patch, PHOENIX-1016.v2.3.0.patch, PHOENIX-1016.v2.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)
Is Hbase table multi version for the cell supported by pheonix supprted yet?
I have a table, which has VERSIONS = 110 for a specific family. Is it possible in Phoenix to get all the versions of a particular cell for hbase table yet? -- Thanks and Best Regards --- Eng. Ahmed Hussien
[jira] [Commented] (PHOENIX-1002) Add support for % operator
[ https://issues.apache.org/jira/browse/PHOENIX-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14060001#comment-14060001 ] Anoop Sam John commented on PHOENIX-1002: - This should go into all branches? The patch applies to master and 4.0 branches. Can you give a patch for 3.0 [~kbuzsaki]? Then I can commit to all branches. Add support for % operator -- Key: PHOENIX-1002 URL: https://issues.apache.org/jira/browse/PHOENIX-1002 Project: Phoenix Issue Type: New Feature Reporter: Thomas D'Silva Attachments: PHOENIX-1002.patch, PHOENIX-1002_2.patch, PHOENIX-1002_3.patch, PHOENIX-1002_4.patch, PHOENIX-1002_5.patch Supporting the % operator would allow using sequences to generate IDs that are less than a maximum number. CREATE SEQUENCE foo.bar SELECT ((NEXT VALUE FOR foo.bar)%1000) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PHOENIX-1002) Add support for % operator
[ https://issues.apache.org/jira/browse/PHOENIX-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated PHOENIX-1002: Assignee: Kyle Buzsaki Add support for % operator -- Key: PHOENIX-1002 URL: https://issues.apache.org/jira/browse/PHOENIX-1002 Project: Phoenix Issue Type: New Feature Reporter: Thomas D'Silva Assignee: Kyle Buzsaki Attachments: PHOENIX-1002.patch, PHOENIX-1002_2.patch, PHOENIX-1002_3.patch, PHOENIX-1002_4.patch, PHOENIX-1002_5.patch Supporting the % operator would allow using sequences to generate IDs that are less than a maximum number. CREATE SEQUENCE foo.bar SELECT ((NEXT VALUE FOR foo.bar)%1000) -- This message was sent by Atlassian JIRA (v6.2#6252)
