[jira] [Commented] (PHOENIX-3338) Move flapping test into test class marked as NotThreadSafe

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15534752#comment-15534752
 ] 

Hudson commented on PHOENIX-3338:
-

FAILURE: Integrated in Jenkins build Phoenix-master #1425 (See 
[https://builds.apache.org/job/Phoenix-master/1425/])
PHOENIX-3338 Move flapping test into test class marked as NotThreadSafe 
(jamestaylor: rev 2895835a8e082e4de3dd5c601ae0003d77431b33)
* (edit) phoenix-core/src/it/java/org/apache/phoenix/tx/TransactionIT.java
* (edit) 
phoenix-core/src/it/java/org/apache/phoenix/tx/NotThreadSafeTransactionIT.java


> Move flapping test into test class marked as NotThreadSafe
> --
>
> Key: PHOENIX-3338
> URL: https://issues.apache.org/jira/browse/PHOENIX-3338
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: James Taylor
> Fix For: 4.9.0
>
>
> The surefire maven parallel test runner has a facility to declare a test 
> class as not eligible to run in parallel by adding a NotThreadSafe 
> annotation. If tests flap, they can be moved in this way and then 
> investigated further as to why they're flapping. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PHOENIX-3340) Dropping column doesn't drop index for local immutable indexes with STORE_COLUMNS_IN_SINGLE_CELL

[Samarth Jain (JIRA)]

Samarth Jain created PHOENIX-3340:
-

 Summary: Dropping column doesn't drop index for local immutable 
indexes with STORE_COLUMNS_IN_SINGLE_CELL
 Key: PHOENIX-3340
 URL: https://issues.apache.org/jira/browse/PHOENIX-3340
 Project: Phoenix
  Issue Type: Bug
Reporter: Samarth Jain


Test case on encode columns branch that fails:
{code}
@Test
public void testDropIndexedColumnImmutableIndex() throws Exception {
helpTestDropIndexedColumn(true);
}

private void helpTestDropIndexedColumn(boolean immutable) throws Exception {
String query;
ResultSet rs;
PreparedStatement stmt;

Properties props = PropertiesUtil.deepCopy(TEST_PROPERTIES);
Connection conn = DriverManager.getConnection(getUrl(), props);
conn.setAutoCommit(false);

// make sure that the tables are empty, but reachable
conn.createStatement().execute(
  "CREATE TABLE " + DATA_TABLE_FULL_NAME
  + " (k VARCHAR NOT NULL PRIMARY KEY, v1 VARCHAR, v2 VARCHAR) " + 
(immutable ? "IMMUTABLE_ROWS = true" : ""));
query = "SELECT * FROM " + DATA_TABLE_FULL_NAME;
rs = conn.createStatement().executeQuery(query);
assertFalse(rs.next());

conn.createStatement().execute(
  "CREATE INDEX " + INDEX_TABLE_NAME + " ON " + DATA_TABLE_FULL_NAME + 
" (v1, v2)");
conn.createStatement().execute(
"CREATE LOCAL INDEX " + LOCAL_INDEX_TABLE_NAME + " ON " + 
DATA_TABLE_FULL_NAME + " (v1, v2)");

query = "SELECT * FROM " + INDEX_TABLE_FULL_NAME;
rs = conn.createStatement().executeQuery(query);
assertFalse(rs.next());

// load some data into the table
stmt = conn.prepareStatement("UPSERT INTO " + DATA_TABLE_FULL_NAME + " 
VALUES(?,?,?)");
stmt.setString(1, "a");
stmt.setString(2, "x");
stmt.setString(3, "1");
stmt.execute();
conn.commit();

assertIndexExists(conn,true);
conn.createStatement().execute("ALTER TABLE " + DATA_TABLE_FULL_NAME + 
" DROP COLUMN v1");
assertIndexExists(conn,false);

query = "SELECT * FROM " + DATA_TABLE_FULL_NAME;
rs = conn.createStatement().executeQuery(query);
assertTrue(rs.next());
assertEquals("a",rs.getString(1));
assertEquals("1",rs.getString(2));
assertFalse(rs.next());

// load some data into the table
stmt = conn.prepareStatement("UPSERT INTO " + DATA_TABLE_FULL_NAME + " 
VALUES(?,?)");
stmt.setString(1, "a");
stmt.setString(2, "2");
stmt.execute();
conn.commit();

query = "SELECT * FROM " + DATA_TABLE_FULL_NAME;
rs = conn.createStatement().executeQuery(query);
assertTrue(rs.next());
assertEquals("a",rs.getString(1));
assertEquals("2",rs.getString(2));
assertFalse(rs.next());
}

{code}

FYI, [~tdsilva]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3339) Some transaction tests are flapping under load

[James Taylor (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15534586#comment-15534586
 ] 

James Taylor commented on PHOENIX-3339:
---

Would you be able to try to get to the bottom of this one, [~poornachandra]?

> Some transaction tests are flapping under load
> --
>
> Key: PHOENIX-3339
> URL: https://issues.apache.org/jira/browse/PHOENIX-3339
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>
> When the transaction-related tests are run in parallel, some of them are 
> flapping. Most of the failures seem related to the transaction visibility 
> filter not doing it's job. The flapping tests have been moved to 
> NotThreadSafeTransactionIT to prevent build failures. We should figure out 
> the root cause to make sure there are no bugs lurking. One recent example 
> test run that failed is here: 
> https://builds.apache.org/job/Phoenix-master/1424
> To reproduce, copy/paste the tests back to TransactionIT and run the test 
> suite through {{mvn verify}}. The only test category that needs to be run is 
> the ParallelStatsEnabledTest category (which takes about 7mins).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3339) Some transaction tests are flapping under load

[James Taylor (JIRA)]

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

James Taylor updated PHOENIX-3339:
--
Description: 
When the transaction-related tests are run in parallel, some of them are 
flapping. Most of the failures seem related to the transaction visibility 
filter not doing it's job. The flapping tests have been moved to 
NotThreadSafeTransactionIT to prevent build failures. We should figure out the 
root cause to make sure there are no bugs lurking. One recent example test run 
that failed is here: https://builds.apache.org/job/Phoenix-master/1424

To reproduce, copy/paste the tests back to TransactionIT and run the test suite 
through {{mvn verify}}. The only test category that needs to be run is the 
ParallelStatsEnabledTest category (which takes about 7mins).

  was:
When the transaction-related tests are run in parallel, some of them are 
flapping. Most of the failures seem related to the transaction visibility 
filter not doing it's job. The flapping tests have been moved to 
NotThreadSafeTransactionIT to prevent build failures. We should figure out the 
root cause to make sure there are no bugs lurking.

To reproduce, copy/paste the tests back to TransactionIT and run the test suite 
through {{mvn verify}}. The only test category that needs to be run is the 
ParallelStatsEnabledTest category (which takes about 7mins).


> Some transaction tests are flapping under load
> --
>
> Key: PHOENIX-3339
> URL: https://issues.apache.org/jira/browse/PHOENIX-3339
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>
> When the transaction-related tests are run in parallel, some of them are 
> flapping. Most of the failures seem related to the transaction visibility 
> filter not doing it's job. The flapping tests have been moved to 
> NotThreadSafeTransactionIT to prevent build failures. We should figure out 
> the root cause to make sure there are no bugs lurking. One recent example 
> test run that failed is here: 
> https://builds.apache.org/job/Phoenix-master/1424
> To reproduce, copy/paste the tests back to TransactionIT and run the test 
> suite through {{mvn verify}}. The only test category that needs to be run is 
> the ParallelStatsEnabledTest category (which takes about 7mins).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PHOENIX-3339) Some transaction tests are flapping under load

[James Taylor (JIRA)]

James Taylor created PHOENIX-3339:
-

 Summary: Some transaction tests are flapping under load
 Key: PHOENIX-3339
 URL: https://issues.apache.org/jira/browse/PHOENIX-3339
 Project: Phoenix
  Issue Type: Bug
Reporter: James Taylor


When the transaction-related tests are run in parallel, some of them are 
flapping. Most of the failures seem related to the transaction visibility 
filter not doing it's job. The flapping tests have been moved to 
NotThreadSafeTransactionIT to prevent build failures. We should figure out the 
root cause to make sure there are no bugs lurking.

To reproduce, copy/paste the tests back to TransactionIT and run the test suite 
through {{mvn verify}}. The only test category that needs to be run is the 
ParallelStatsEnabledTest category (which takes about 7mins).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PHOENIX-3338) Move flapping test into test class marked as NotThreadSafe

[James Taylor (JIRA)]

James Taylor created PHOENIX-3338:
-

 Summary: Move flapping test into test class marked as NotThreadSafe
 Key: PHOENIX-3338
 URL: https://issues.apache.org/jira/browse/PHOENIX-3338
 Project: Phoenix
  Issue Type: Sub-task
Reporter: James Taylor
Assignee: James Taylor
 Fix For: 4.9.0


The surefire maven parallel test runner has a facility to declare a test class 
as not eligible to run in parallel by adding a NotThreadSafe annotation. If 
tests flap, they can be moved in this way and then investigated further as to 
why they're flapping. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3242) Support CREATE OR REPLACE FUNCTION in Phoenix-Calcite Integration

[Maryann Xue (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15534432#comment-15534432
 ] 

Maryann Xue commented on PHOENIX-3242:
--

Thank you, [~rajeshbabu], for the WIP patch! I have a quick conclusion here:
As [~julianhyde] mentioned this morning, making UDF work takes two stages: sql 
validation and runtime method call. I tried running the test case you pointed 
out and found that it could not even go through the first stage, validation. 
And the reason was that you re-used ScalarFunctionImpl from Calcite and passed 
"evaluate()" as the method while its signature was not matchable for 
"myfunction(varchar)" at all. The most straight-forward solution is to have our 
own implementation class for Function and give it whatever information we'll 
need at runtime, including tenant id, JAR path, UDF class name, etc. Then in 
CalciteUtils, when translating SqlKind.OTHER_FUNCTION, for 
{{SqlUserDefinedFunction}} SqlOperator, you'll unwrap our own implementation 
class and create a corresponding Phoenix UDFExpression.

> Support CREATE OR REPLACE FUNCTION in Phoenix-Calcite Integration
> -
>
> Key: PHOENIX-3242
> URL: https://issues.apache.org/jira/browse/PHOENIX-3242
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
>  Labels: calcite
> Attachments: PHOENIX-3242-wip.patch, PHOENIX-3242_select-wip.patch, 
> PHOENIX-3242_v1.patch, PHOENIX-3242_v2.patch, PHOENIX-3242_v3.patch, 
> PHOENIX-3242_v4.patch, PHOENIX-3242_v5.patch, PHOENIX-3242_v6.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

useful links to track calcite branch test results over time

[James Taylor]

FYI, I've enabled the Jenkins build on the calcite branch to run the
integration test even if the unit tests fail. To see test failures over
time see:
https://builds.apache.org/job/Phoenix-calcite/16/testReport/history/countGraph/png?start=0end=25

The red shows failed tests while the blue is all tests. The spike is due to
the fact that the integration tests are running now (~4K additional tests).

A related view with prettier graphs can be found here:

https://builds.apache.org/job/Phoenix-calcite/test_results_analyzer/

Scroll to the bottom past the not very useful table to get to some nice
graphs on pass rates over time. It's a bit slow to load, so be patient.

Thanks,
James

[jira] [Commented] (PHOENIX-3337) Continue calcite branch build on unit test failure

[Maryann Xue (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15534042#comment-15534042
 ] 

Maryann Xue commented on PHOENIX-3337:
--

Thank you, [~jamestaylor], for making this check-in!

> Continue calcite branch build on unit test failure
> --
>
> Key: PHOENIX-3337
> URL: https://issues.apache.org/jira/browse/PHOENIX-3337
> Project: Phoenix
>  Issue Type: Test
>Reporter: James Taylor
>Assignee: James Taylor
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (PHOENIX-3337) Continue calcite branch build on unit test failure

[James Taylor (JIRA)]

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

James Taylor resolved PHOENIX-3337.
---
Resolution: Fixed
  Assignee: James Taylor

> Continue calcite branch build on unit test failure
> --
>
> Key: PHOENIX-3337
> URL: https://issues.apache.org/jira/browse/PHOENIX-3337
> Project: Phoenix
>  Issue Type: Test
>Reporter: James Taylor
>Assignee: James Taylor
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PHOENIX-3337) Continue calcite branch build on unit test failure

[James Taylor (JIRA)]

James Taylor created PHOENIX-3337:
-

 Summary: Continue calcite branch build on unit test failure
 Key: PHOENIX-3337
 URL: https://issues.apache.org/jira/browse/PHOENIX-3337
 Project: Phoenix
  Issue Type: Test
Reporter: James Taylor






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [ANNOUNCE] Apache Phoenix 4.8.1 is available for download

[James Taylor]

Apache Phoenix enables OLTP and operational analytics for Hadoop through
SQL support using HBase as it's backing store and integrates with other
projects in the ecosystem such as Spark, Hive, Pig, Flume, and MapReduce.

On Tue, Sep 27, 2016 at 10:27 PM,  wrote:

> The Phoenix Team is pleased to announce the immediate release of Apache
> Phoenix 4.8.1.
> Download it from your favorite Apache mirror [1].
>
> Apache Phoenix 4.8.1 a bug fix release for the Phoenix 4.8 release line,
> compatible with Apache HBase 0.98, 1.0, 1.1 & 1.2.
>
> This release fixes the following 43 issues:
> [PHOENIX-1367] - VIEW derived from another VIEW doesn't use parent
> VIEW indexes
> [PHOENIX-3195] - Slight safety improvement for using
> DistinctPrefixFilter
> [PHOENIX-3228] - Index tables should not be configured with a
> custom/smaller MAX_FILESIZE
> [PHOENIX-930] - duplicated columns cause query exception and drop
> table exception
> [PHOENIX-1647] - Correctly return that Phoenix supports schema name
> references in DatabaseMetaData
> [PHOENIX-2336] - Queries with small case column-names return empty
> result-set when working with Spark Datasource Plugin
> [PHOENIX-2474] - Cannot round to a negative precision (to the left of
> the decimal)
> [PHOENIX-2641] - Implicit wildcard in LIKE predicate search pattern
> [PHOENIX-2645] - Wildcard characters do not match newline characters
> [PHOENIX-2853] - Delete Immutable rows from View does not work if
> immutable index(secondary index) exists
> [PHOENIX-2944] - DATE Comparison Broken
> [PHOENIX-2946] - Projected comparison between date and timestamp
> columns always returns true
> [PHOENIX-2995] - Write performance severely degrades with large number
> of views
> [PHOENIX-3046] - NOT LIKE with wildcard unexpectedly returns results
> [PHOENIX-3054] - Counting zero null rows returns an empty result set
> [PHOENIX-3072] - Deadlock on region opening with secondary index
> recovery
> [PHOENIX-3148] - Reduce size of PTable so that more tables can be
> cached in the metada cache.
> [PHOENIX-3162] - TableNotFoundException might be thrown when an index
> dropped while upserting.
> [PHOENIX-3164] - PhoenixConnection leak in PQS with security enabled
> [PHOENIX-3170] - Remove the futuretask from the list if
> StaleRegionBoundaryCacheException is thrown while initializing the
> scanners
> [PHOENIX-3175] - Unnecessary UGI proxy user impersonation check
> [PHOENIX-3185] - Error: ERROR 514 (42892): A duplicate column name was
> detected in the object definition or ALTER TABLE statement.
> columnName=TEST_TABLE.C1 (state=42892,code=514)
> [PHOENIX-3189] - HBase/ZooKeeper connection leaks when providing
> principal/keytab in JDBC url
> [PHOENIX-3203] - Tenant cache lookup in Global Cache fails in certain
> conditions
> [PHOENIX-3207] - Fix compilation failure on 4.8-HBase-1.2,
> 4.8-HBase-1.1 and 4.8-HBase-1.0 branches after PHOENIX-3148
> [PHOENIX-3210] - Exception trying to cast Double to BigDecimal in
> UpsertCompiler
> [PHOENIX-3223] - Add hadoop classpath to PQS classpath
> [PHOENIX-3230] - Upgrade code running concurrently on different JVMs
> could make clients unusuable
> [PHOENIX-3237] - Automatic rebuild of disabled index will fail if
> indexes of two tables are disabled at the same time
> [PHOENIX-3246] - U+2002 (En Space) not handled as whitespace in grammar
> [PHOENIX-3260] - MetadataRegionObserver.postOpen() can prevent region
> server from shutting down for a long duration
> [PHOENIX-3268] - Upgrade to Tephra 0.9.0
> [PHOENIX-3280] - Automatic attempt to rebuild all disabled index
> [PHOENIX-3291] - Do not throw return value of Throwables#propagate call
> [PHOENIX-3307] - Backward compatibility fails for tables with index
> (4.7.0 client - 4.8.1 server)
> [PHOENIX-3323] - make_rc script fails to build the RC
> [PHOENIX-2785] - Do not store NULLs for immutable tables
> [PHOENIX-3081] - MIsleading exception on async stats update after
> major compaction
> [PHOENIX-3116] - Support incompatible HBase 1.1.5 and HBase 1.2.2
> [PHOENIX-808] - Create snapshot of SYSTEM.CATALOG prior to upgrade and
> restore on any failure
> [PHOENIX-2990] - Ensure documentation on "time/date"
> datatypes/functions acknowledge lack of JDBC compliance
> [PHOENIX-2991] - Add missing documentation for functions
> [PHOENIX-3255] - Increase test coverage for TIMESTAMP
>
> See also the full release notes [2].
>
> Yours,
> The Apache Phoenix Team
>
> [1] http://www.apache.org/dyn/closer.lua/phoenix/
> [2] https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12315120=12337964
>
>

[jira] [Issue Comment Deleted] (PHOENIX-3298) Create Table: Single column primary key may not be null

[Eric Lomore (JIRA)]

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

Eric Lomore updated PHOENIX-3298:
-
Comment: was deleted

(was: Ah! I didn't realize they were non-primitive on the Phoenix side. Will 
explore this, thanks James!)

> Create Table: Single column primary key may not be null
> ---
>
> Key: PHOENIX-3298
> URL: https://issues.apache.org/jira/browse/PHOENIX-3298
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: Eric Lomore
>Assignee: Eric Lomore
> Attachments: PHOENIX-3298-WIP
>
>
> Create table statements with a single column currently must have "NOT NULL" 
> identifier to pass tests.
> Running this code results in failure
> {code}CREATE TABLE t (k VARCHAR PRIMARY KEY DESC){code}
> While this allows tests to pass
> {code}CREATE TABLE t (k VARCHAR NOT NULL PRIMARY KEY DESC){code}
> Must either enforce the not null condition and update test cases, or apply a 
> fix.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3298) Create Table: Single column primary key may not be null

[Eric Lomore (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533846#comment-15533846
 ] 

Eric Lomore commented on PHOENIX-3298:
--

Ah! I didn't realize they were non-primitive on the Phoenix side. Will explore 
this, thanks James!

> Create Table: Single column primary key may not be null
> ---
>
> Key: PHOENIX-3298
> URL: https://issues.apache.org/jira/browse/PHOENIX-3298
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: Eric Lomore
>Assignee: Eric Lomore
> Attachments: PHOENIX-3298-WIP
>
>
> Create table statements with a single column currently must have "NOT NULL" 
> identifier to pass tests.
> Running this code results in failure
> {code}CREATE TABLE t (k VARCHAR PRIMARY KEY DESC){code}
> While this allows tests to pass
> {code}CREATE TABLE t (k VARCHAR NOT NULL PRIMARY KEY DESC){code}
> Must either enforce the not null condition and update test cases, or apply a 
> fix.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3264) Allow TRUE and FALSE to be used as literal constants

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533807#comment-15533807
 ] 

ASF GitHub Bot commented on PHOENIX-3264:
-

Github user lomoree commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81216671
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
+
+SqlParserPos POS = SqlParserPos.ZERO;
+final SqlNodeList selectList =
+new SqlNodeList(
+Collections.singletonList(literal),
+SqlParserPos.ZERO);
+
+
+String sql = new SqlSelect(POS, SqlNodeList.EMPTY, selectList, 
null, null, null, null,
+SqlNodeList.EMPTY, null, null, null).toString();
+SqlNode sqlNode = planner.parse(sql);
+sqlNode = planner.validate(sqlNode);
+Project proj = (Project) (planner.rel(sqlNode).rel);
+RexNode rex = proj.getChildExps().get(0);
+
+Expression e = CalciteUtils.toExpression(rex, implementor);
+ImmutableBytesWritable ptr = new ImmutableBytesWritable();
+e = ExpressionUtil.getConstantExpression(e, ptr);
+Object ret = e.getDataType().toObject(ptr);
+if(ret instanceof NlsString){
--- End diff --

Yes I meant that as well. I think it's because we had originally intended 
to use Calcite utilities to do this. I just ran through a debugger and all 
inputs parse down to either a Char or a String. It is definitely covered by 
test cases.


> Allow TRUE and FALSE to be used as literal constants
> 
>
> Key: PHOENIX-3264
> URL: https://issues.apache.org/jira/browse/PHOENIX-3264
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Eric Lomore
> Attachments: Sql2RelImplementation.png, SqlLiteral.png, 
> SqlNodeToRexConverterImpl.png, SqlOptionNode.png, objectdependencies.png, 
> objectdependencies2.png, stacktrace.png
>
>
> Phoenix supports TRUE and FALSE as boolean literals, but perhaps Calcite 
> doesn't? Looks like this is leading to a fair number of failures.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] phoenix pull request #212: PHOENIX-3264 Allow TRUE and FALSE to be used as l...

[lomoree]

Github user lomoree commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81216671
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
+
+SqlParserPos POS = SqlParserPos.ZERO;
+final SqlNodeList selectList =
+new SqlNodeList(
+Collections.singletonList(literal),
+SqlParserPos.ZERO);
+
+
+String sql = new SqlSelect(POS, SqlNodeList.EMPTY, selectList, 
null, null, null, null,
+SqlNodeList.EMPTY, null, null, null).toString();
+SqlNode sqlNode = planner.parse(sql);
+sqlNode = planner.validate(sqlNode);
+Project proj = (Project) (planner.rel(sqlNode).rel);
+RexNode rex = proj.getChildExps().get(0);
+
+Expression e = CalciteUtils.toExpression(rex, implementor);
+ImmutableBytesWritable ptr = new ImmutableBytesWritable();
+e = ExpressionUtil.getConstantExpression(e, ptr);
+Object ret = e.getDataType().toObject(ptr);
+if(ret instanceof NlsString){
--- End diff --

Yes I meant that as well. I think it's because we had originally intended 
to use Calcite utilities to do this. I just ran through a debugger and all 
inputs parse down to either a Char or a String. It is definitely covered by 
test cases.


---
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-3254) IndexId Sequence is incremented even if index exists already.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533778#comment-15533778
 ] 

Hudson commented on PHOENIX-3254:
-

FAILURE: Integrated in Jenkins build Phoenix-master #1424 (See 
[https://builds.apache.org/job/Phoenix-master/1424/])
PHOENIX-3254 IndexId Sequence is incremented even if index exists 
(ankitsinghal59: rev 655fe2be3d30f2b8277563920c15a357eb74bcde)
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/generated/MetaDataProtos.java
* (edit) 
phoenix-core/src/it/java/org/apache/phoenix/end2end/index/LocalIndexIT.java
* (edit) 
phoenix-core/src/test/java/org/apache/phoenix/compile/TenantSpecificViewIndexCompileTest.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServices.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java
* (edit) 
phoenix-core/src/it/java/org/apache/phoenix/end2end/AppendOnlySchemaIT.java
* (edit) phoenix-protocol/src/main/MetaDataService.proto
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/query/DelegateConnectionQueryServices.java
* (edit) phoenix-core/src/test/java/org/apache/phoenix/query/BaseTest.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataProtocol.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionlessQueryServicesImpl.java
* (edit) 
phoenix-core/src/it/java/org/apache/phoenix/end2end/index/ViewIndexIT.java
* (edit) 
phoenix-core/src/it/java/org/apache/phoenix/end2end/TenantSpecificViewIndexIT.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/schema/MetaDataClient.java


> IndexId Sequence is incremented even if index exists already.
> -
>
> Key: PHOENIX-3254
> URL: https://issues.apache.org/jira/browse/PHOENIX-3254
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3254.patch, PHOENIX-3254_v1.patch, 
> PHOENIX-3254_wip.patch
>
>
> As we are incrementing sequence at the client even if we are not going to 
> create a index (in case index already exists and user is using CREATE INDEX 
> IF NOT EXISTS) or DDL failed in later stage(due to parent table not found or 
> something).
> If this keeps on happening then user may reach the limit of Short.MAX_VALUE 
> and TOO_MANY_INDEXES exception will be thrown if user tries to create a new 
> index.
> To prevent, this we should increment sequences when we are about to create a 
> index at server.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3264) Allow TRUE and FALSE to be used as literal constants

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533770#comment-15533770
 ] 

ASF GitHub Bot commented on PHOENIX-3264:
-

Github user maryannxue commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81214035
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
+
+SqlParserPos POS = SqlParserPos.ZERO;
+final SqlNodeList selectList =
+new SqlNodeList(
+Collections.singletonList(literal),
+SqlParserPos.ZERO);
+
+
+String sql = new SqlSelect(POS, SqlNodeList.EMPTY, selectList, 
null, null, null, null,
--- End diff --

Thank you, Eric, for doing a nice job and trying to work things out in the 
best you could find! But if you run into issues like this next time, you can 
just ping me quickly. I can probably give you some useful information since 
I've had quite some experience dealing with Calcite.


> Allow TRUE and FALSE to be used as literal constants
> 
>
> Key: PHOENIX-3264
> URL: https://issues.apache.org/jira/browse/PHOENIX-3264
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Eric Lomore
> Attachments: Sql2RelImplementation.png, SqlLiteral.png, 
> SqlNodeToRexConverterImpl.png, SqlOptionNode.png, objectdependencies.png, 
> objectdependencies2.png, stacktrace.png
>
>
> Phoenix supports TRUE and FALSE as boolean literals, but perhaps Calcite 
> doesn't? Looks like this is leading to a fair number of failures.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] phoenix pull request #212: PHOENIX-3264 Allow TRUE and FALSE to be used as l...

[maryannxue]

Github user maryannxue commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81214035
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
+
+SqlParserPos POS = SqlParserPos.ZERO;
+final SqlNodeList selectList =
+new SqlNodeList(
+Collections.singletonList(literal),
+SqlParserPos.ZERO);
+
+
+String sql = new SqlSelect(POS, SqlNodeList.EMPTY, selectList, 
null, null, null, null,
--- End diff --

Thank you, Eric, for doing a nice job and trying to work things out in the 
best you could find! But if you run into issues like this next time, you can 
just ping me quickly. I can probably give you some useful information since 
I've had quite some experience dealing with Calcite.


---
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-3264) Allow TRUE and FALSE to be used as literal constants

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533755#comment-15533755
 ] 

ASF GitHub Bot commented on PHOENIX-3264:
-

Github user maryannxue commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81212867
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
+
+SqlParserPos POS = SqlParserPos.ZERO;
+final SqlNodeList selectList =
+new SqlNodeList(
+Collections.singletonList(literal),
+SqlParserPos.ZERO);
+
+
+String sql = new SqlSelect(POS, SqlNodeList.EMPTY, selectList, 
null, null, null, null,
+SqlNodeList.EMPTY, null, null, null).toString();
+SqlNode sqlNode = planner.parse(sql);
+sqlNode = planner.validate(sqlNode);
+Project proj = (Project) (planner.rel(sqlNode).rel);
+RexNode rex = proj.getChildExps().get(0);
+
+Expression e = CalciteUtils.toExpression(rex, implementor);
+ImmutableBytesWritable ptr = new ImmutableBytesWritable();
+e = ExpressionUtil.getConstantExpression(e, ptr);
+Object ret = e.getDataType().toObject(ptr);
+if(ret instanceof NlsString){
--- End diff --

I was talking about the "if" block, the NlsString is a Calcite thing, so 
once we have converted a RexNode into an Phoenix Expression, there should only 
be Java String objects. So you should probably just remove it and verify with a 
test case (maybe already covered by an existing test case).


> Allow TRUE and FALSE to be used as literal constants
> 
>
> Key: PHOENIX-3264
> URL: https://issues.apache.org/jira/browse/PHOENIX-3264
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Eric Lomore
> Attachments: Sql2RelImplementation.png, SqlLiteral.png, 
> SqlNodeToRexConverterImpl.png, SqlOptionNode.png, objectdependencies.png, 
> objectdependencies2.png, stacktrace.png
>
>
> Phoenix supports TRUE and FALSE as boolean literals, but perhaps Calcite 
> doesn't? Looks like this is leading to a fair number of failures.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] phoenix pull request #212: PHOENIX-3264 Allow TRUE and FALSE to be used as l...

[maryannxue]

Github user maryannxue commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81212867
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
+
+SqlParserPos POS = SqlParserPos.ZERO;
+final SqlNodeList selectList =
+new SqlNodeList(
+Collections.singletonList(literal),
+SqlParserPos.ZERO);
+
+
+String sql = new SqlSelect(POS, SqlNodeList.EMPTY, selectList, 
null, null, null, null,
+SqlNodeList.EMPTY, null, null, null).toString();
+SqlNode sqlNode = planner.parse(sql);
+sqlNode = planner.validate(sqlNode);
+Project proj = (Project) (planner.rel(sqlNode).rel);
+RexNode rex = proj.getChildExps().get(0);
+
+Expression e = CalciteUtils.toExpression(rex, implementor);
+ImmutableBytesWritable ptr = new ImmutableBytesWritable();
+e = ExpressionUtil.getConstantExpression(e, ptr);
+Object ret = e.getDataType().toObject(ptr);
+if(ret instanceof NlsString){
--- End diff --

I was talking about the "if" block, the NlsString is a Calcite thing, so 
once we have converted a RexNode into an Phoenix Expression, there should only 
be Java String objects. So you should probably just remove it and verify with a 
test case (maybe already covered by an existing 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-3264) Allow TRUE and FALSE to be used as literal constants

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533744#comment-15533744
 ] 

ASF GitHub Bot commented on PHOENIX-3264:
-

Github user lomoree commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81212299
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
+
+SqlParserPos POS = SqlParserPos.ZERO;
+final SqlNodeList selectList =
+new SqlNodeList(
+Collections.singletonList(literal),
+SqlParserPos.ZERO);
+
+
+String sql = new SqlSelect(POS, SqlNodeList.EMPTY, selectList, 
null, null, null, null,
+SqlNodeList.EMPTY, null, null, null).toString();
+SqlNode sqlNode = planner.parse(sql);
+sqlNode = planner.validate(sqlNode);
+Project proj = (Project) (planner.rel(sqlNode).rel);
+RexNode rex = proj.getChildExps().get(0);
+
+Expression e = CalciteUtils.toExpression(rex, implementor);
+ImmutableBytesWritable ptr = new ImmutableBytesWritable();
+e = ExpressionUtil.getConstantExpression(e, ptr);
+Object ret = e.getDataType().toObject(ptr);
+if(ret instanceof NlsString){
+ret = ((NlsString) ret).toString();
+}
+return ret;
+}
+catch (Exception e){
+throw new RuntimeException("Could not convert literal to its 
object type: " + e);
--- End diff --

Will amend this, thanks!


> Allow TRUE and FALSE to be used as literal constants
> 
>
> Key: PHOENIX-3264
> URL: https://issues.apache.org/jira/browse/PHOENIX-3264
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Eric Lomore
> Attachments: Sql2RelImplementation.png, SqlLiteral.png, 
> SqlNodeToRexConverterImpl.png, SqlOptionNode.png, objectdependencies.png, 
> objectdependencies2.png, stacktrace.png
>
>
> Phoenix supports TRUE and FALSE as boolean literals, but perhaps Calcite 
> doesn't? Looks like this is leading to a fair number of failures.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3264) Allow TRUE and FALSE to be used as literal constants

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533743#comment-15533743
 ] 

ASF GitHub Bot commented on PHOENIX-3264:
-

Github user lomoree commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81212263
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
+
+SqlParserPos POS = SqlParserPos.ZERO;
+final SqlNodeList selectList =
+new SqlNodeList(
+Collections.singletonList(literal),
+SqlParserPos.ZERO);
+
+
+String sql = new SqlSelect(POS, SqlNodeList.EMPTY, selectList, 
null, null, null, null,
+SqlNodeList.EMPTY, null, null, null).toString();
+SqlNode sqlNode = planner.parse(sql);
+sqlNode = planner.validate(sqlNode);
+Project proj = (Project) (planner.rel(sqlNode).rel);
+RexNode rex = proj.getChildExps().get(0);
+
+Expression e = CalciteUtils.toExpression(rex, implementor);
+ImmutableBytesWritable ptr = new ImmutableBytesWritable();
+e = ExpressionUtil.getConstantExpression(e, ptr);
+Object ret = e.getDataType().toObject(ptr);
+if(ret instanceof NlsString){
--- End diff --

I'm not sure if it's necessary, but decided to use it per James' 
recommendation. He might have some insight on why it's needed.


> Allow TRUE and FALSE to be used as literal constants
> 
>
> Key: PHOENIX-3264
> URL: https://issues.apache.org/jira/browse/PHOENIX-3264
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Eric Lomore
> Attachments: Sql2RelImplementation.png, SqlLiteral.png, 
> SqlNodeToRexConverterImpl.png, SqlOptionNode.png, objectdependencies.png, 
> objectdependencies2.png, stacktrace.png
>
>
> Phoenix supports TRUE and FALSE as boolean literals, but perhaps Calcite 
> doesn't? Looks like this is leading to a fair number of failures.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] phoenix pull request #212: PHOENIX-3264 Allow TRUE and FALSE to be used as l...

[lomoree]

Github user lomoree commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81212299
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
+
+SqlParserPos POS = SqlParserPos.ZERO;
+final SqlNodeList selectList =
+new SqlNodeList(
+Collections.singletonList(literal),
+SqlParserPos.ZERO);
+
+
+String sql = new SqlSelect(POS, SqlNodeList.EMPTY, selectList, 
null, null, null, null,
+SqlNodeList.EMPTY, null, null, null).toString();
+SqlNode sqlNode = planner.parse(sql);
+sqlNode = planner.validate(sqlNode);
+Project proj = (Project) (planner.rel(sqlNode).rel);
+RexNode rex = proj.getChildExps().get(0);
+
+Expression e = CalciteUtils.toExpression(rex, implementor);
+ImmutableBytesWritable ptr = new ImmutableBytesWritable();
+e = ExpressionUtil.getConstantExpression(e, ptr);
+Object ret = e.getDataType().toObject(ptr);
+if(ret instanceof NlsString){
+ret = ((NlsString) ret).toString();
+}
+return ret;
+}
+catch (Exception e){
+throw new RuntimeException("Could not convert literal to its 
object type: " + e);
--- End diff --

Will amend this, thanks!


---
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 #212: PHOENIX-3264 Allow TRUE and FALSE to be used as l...

[lomoree]

Github user lomoree commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81212263
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
+
+SqlParserPos POS = SqlParserPos.ZERO;
+final SqlNodeList selectList =
+new SqlNodeList(
+Collections.singletonList(literal),
+SqlParserPos.ZERO);
+
+
+String sql = new SqlSelect(POS, SqlNodeList.EMPTY, selectList, 
null, null, null, null,
+SqlNodeList.EMPTY, null, null, null).toString();
+SqlNode sqlNode = planner.parse(sql);
+sqlNode = planner.validate(sqlNode);
+Project proj = (Project) (planner.rel(sqlNode).rel);
+RexNode rex = proj.getChildExps().get(0);
+
+Expression e = CalciteUtils.toExpression(rex, implementor);
+ImmutableBytesWritable ptr = new ImmutableBytesWritable();
+e = ExpressionUtil.getConstantExpression(e, ptr);
+Object ret = e.getDataType().toObject(ptr);
+if(ret instanceof NlsString){
--- End diff --

I'm not sure if it's necessary, but decided to use it per James' 
recommendation. He might have some insight on why it's needed.


---
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-3264) Allow TRUE and FALSE to be used as literal constants

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533724#comment-15533724
 ] 

ASF GitHub Bot commented on PHOENIX-3264:
-

Github user maryannxue commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81211365
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
--- End diff --

Maybe let's leave it here in CalciteUtils if that works. They don't 
necessarily belong anywhere, and CalciteUtils seems to be a class best for 
hiding all the details.


> Allow TRUE and FALSE to be used as literal constants
> 
>
> Key: PHOENIX-3264
> URL: https://issues.apache.org/jira/browse/PHOENIX-3264
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Eric Lomore
> Attachments: Sql2RelImplementation.png, SqlLiteral.png, 
> SqlNodeToRexConverterImpl.png, SqlOptionNode.png, objectdependencies.png, 
> objectdependencies2.png, stacktrace.png
>
>
> Phoenix supports TRUE and FALSE as boolean literals, but perhaps Calcite 
> doesn't? Looks like this is leading to a fair number of failures.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] phoenix pull request #212: PHOENIX-3264 Allow TRUE and FALSE to be used as l...

[maryannxue]

Github user maryannxue commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81211365
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
--- End diff --

Maybe let's leave it here in CalciteUtils if that works. They don't 
necessarily belong anywhere, and CalciteUtils seems to be a class best for 
hiding all the details.


---
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-3264) Allow TRUE and FALSE to be used as literal constants

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533716#comment-15533716
 ] 

ASF GitHub Bot commented on PHOENIX-3264:
-

Github user lomoree commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81210767
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
--- End diff --

I could also abstract this to the SqlOptionNode and pass it in to this 
method. I had that at one point but ended up opting for this since the code 
didn't seem like it belonged there. Let me know which you prefer.


> Allow TRUE and FALSE to be used as literal constants
> 
>
> Key: PHOENIX-3264
> URL: https://issues.apache.org/jira/browse/PHOENIX-3264
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Eric Lomore
> Attachments: Sql2RelImplementation.png, SqlLiteral.png, 
> SqlNodeToRexConverterImpl.png, SqlOptionNode.png, objectdependencies.png, 
> objectdependencies2.png, stacktrace.png
>
>
> Phoenix supports TRUE and FALSE as boolean literals, but perhaps Calcite 
> doesn't? Looks like this is leading to a fair number of failures.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] phoenix pull request #212: PHOENIX-3264 Allow TRUE and FALSE to be used as l...

[lomoree]

Github user lomoree commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81210767
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
--- End diff --

I could also abstract this to the SqlOptionNode and pass it in to this 
method. I had that at one point but ended up opting for this since the code 
didn't seem like it belonged there. Let me know which you prefer.


---
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-3264) Allow TRUE and FALSE to be used as literal constants

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533711#comment-15533711
 ] 

ASF GitHub Bot commented on PHOENIX-3264:
-

Github user maryannxue commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81210515
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
+
+SqlParserPos POS = SqlParserPos.ZERO;
+final SqlNodeList selectList =
+new SqlNodeList(
+Collections.singletonList(literal),
+SqlParserPos.ZERO);
+
+
+String sql = new SqlSelect(POS, SqlNodeList.EMPTY, selectList, 
null, null, null, null,
--- End diff --

Ok, I once ran into this as well. Let's just do string then.


> Allow TRUE and FALSE to be used as literal constants
> 
>
> Key: PHOENIX-3264
> URL: https://issues.apache.org/jira/browse/PHOENIX-3264
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Eric Lomore
> Attachments: Sql2RelImplementation.png, SqlLiteral.png, 
> SqlNodeToRexConverterImpl.png, SqlOptionNode.png, objectdependencies.png, 
> objectdependencies2.png, stacktrace.png
>
>
> Phoenix supports TRUE and FALSE as boolean literals, but perhaps Calcite 
> doesn't? Looks like this is leading to a fair number of failures.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] phoenix pull request #212: PHOENIX-3264 Allow TRUE and FALSE to be used as l...

[lomoree]

Github user lomoree commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81210455
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
--- End diff --

Agreed, will update.


---
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 #212: PHOENIX-3264 Allow TRUE and FALSE to be used as l...

[maryannxue]

Github user maryannxue commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81210515
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
+
+SqlParserPos POS = SqlParserPos.ZERO;
+final SqlNodeList selectList =
+new SqlNodeList(
+Collections.singletonList(literal),
+SqlParserPos.ZERO);
+
+
+String sql = new SqlSelect(POS, SqlNodeList.EMPTY, selectList, 
null, null, null, null,
--- End diff --

Ok, I once ran into this as well. Let's just do string then.


---
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-3264) Allow TRUE and FALSE to be used as literal constants

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533710#comment-15533710
 ] 

ASF GitHub Bot commented on PHOENIX-3264:
-

Github user lomoree commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81210455
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
--- End diff --

Agreed, will update.


> Allow TRUE and FALSE to be used as literal constants
> 
>
> Key: PHOENIX-3264
> URL: https://issues.apache.org/jira/browse/PHOENIX-3264
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Eric Lomore
> Attachments: Sql2RelImplementation.png, SqlLiteral.png, 
> SqlNodeToRexConverterImpl.png, SqlOptionNode.png, objectdependencies.png, 
> objectdependencies2.png, stacktrace.png
>
>
> Phoenix supports TRUE and FALSE as boolean literals, but perhaps Calcite 
> doesn't? Looks like this is leading to a fair number of failures.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3264) Allow TRUE and FALSE to be used as literal constants

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533705#comment-15533705
 ] 

ASF GitHub Bot commented on PHOENIX-3264:
-

Github user lomoree commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81210093
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
+
+SqlParserPos POS = SqlParserPos.ZERO;
+final SqlNodeList selectList =
+new SqlNodeList(
+Collections.singletonList(literal),
+SqlParserPos.ZERO);
+
+
+String sql = new SqlSelect(POS, SqlNodeList.EMPTY, selectList, 
null, null, null, null,
--- End diff --

I tried desperately to do this, but Calcite has pretty strict enforcement 
on Sql States. When the node is created its in STATE 1: READY, and it will not 
allow you to go straight to a validation state. Is there some way of overriding 
this?


> Allow TRUE and FALSE to be used as literal constants
> 
>
> Key: PHOENIX-3264
> URL: https://issues.apache.org/jira/browse/PHOENIX-3264
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Eric Lomore
> Attachments: Sql2RelImplementation.png, SqlLiteral.png, 
> SqlNodeToRexConverterImpl.png, SqlOptionNode.png, objectdependencies.png, 
> objectdependencies2.png, stacktrace.png
>
>
> Phoenix supports TRUE and FALSE as boolean literals, but perhaps Calcite 
> doesn't? Looks like this is leading to a fair number of failures.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] phoenix pull request #212: PHOENIX-3264 Allow TRUE and FALSE to be used as l...

[lomoree]

Github user lomoree commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81210093
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
+
+SqlParserPos POS = SqlParserPos.ZERO;
+final SqlNodeList selectList =
+new SqlNodeList(
+Collections.singletonList(literal),
+SqlParserPos.ZERO);
+
+
+String sql = new SqlSelect(POS, SqlNodeList.EMPTY, selectList, 
null, null, null, null,
--- End diff --

I tried desperately to do this, but Calcite has pretty strict enforcement 
on Sql States. When the node is created its in STATE 1: READY, and it will not 
allow you to go straight to a validation state. Is there some way of overriding 
this?


---
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 #212: PHOENIX-3264 Allow TRUE and FALSE to be used as l...

[maryannxue]

Github user maryannxue commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81200946
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
--- End diff --

Other convertXXX methods are to convert RexNode to Expression, so I'm 
thinking something like "convertSqlLiteral(...)" could be less confusing?


---
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-3264) Allow TRUE and FALSE to be used as literal constants

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533605#comment-15533605
 ] 

ASF GitHub Bot commented on PHOENIX-3264:
-

Github user maryannxue commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81202889
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
+
+SqlParserPos POS = SqlParserPos.ZERO;
+final SqlNodeList selectList =
+new SqlNodeList(
+Collections.singletonList(literal),
+SqlParserPos.ZERO);
+
+
+String sql = new SqlSelect(POS, SqlNodeList.EMPTY, selectList, 
null, null, null, null,
+SqlNodeList.EMPTY, null, null, null).toString();
+SqlNode sqlNode = planner.parse(sql);
+sqlNode = planner.validate(sqlNode);
+Project proj = (Project) (planner.rel(sqlNode).rel);
+RexNode rex = proj.getChildExps().get(0);
+
+Expression e = CalciteUtils.toExpression(rex, implementor);
+ImmutableBytesWritable ptr = new ImmutableBytesWritable();
+e = ExpressionUtil.getConstantExpression(e, ptr);
+Object ret = e.getDataType().toObject(ptr);
+if(ret instanceof NlsString){
+ret = ((NlsString) ret).toString();
+}
+return ret;
+}
+catch (Exception e){
+throw new RuntimeException("Could not convert literal to its 
object type: " + e);
--- End diff --

Normally you don't append the Exception itself to the end of the error 
message. You message should include the exact SqlLiteral it failed to convert 
and add the original Exception as inner exception.


> Allow TRUE and FALSE to be used as literal constants
> 
>
> Key: PHOENIX-3264
> URL: https://issues.apache.org/jira/browse/PHOENIX-3264
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Eric Lomore
> Attachments: Sql2RelImplementation.png, SqlLiteral.png, 
> SqlNodeToRexConverterImpl.png, SqlOptionNode.png, objectdependencies.png, 
> objectdependencies2.png, stacktrace.png
>
>
> Phoenix supports TRUE and FALSE as boolean literals, but perhaps Calcite 
> doesn't? Looks like this is leading to a fair number of failures.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3264) Allow TRUE and FALSE to be used as literal constants

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533600#comment-15533600
 ] 

ASF GitHub Bot commented on PHOENIX-3264:
-

Github user maryannxue commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81203125
  
--- Diff: 
phoenix-core/src/main/java/org/apache/calcite/sql/SqlOptionNode.java ---
@@ -38,12 +41,10 @@ public SqlOptionNode(SqlParserPos pos, SqlIdentifier 
key, SqlLiteral literal) {
 familyName = key.names.get(0);
 propertyName = key.names.get(1);
 }
-final Object v = SqlLiteral.value(literal);
-if (v instanceof NlsString) {
-value = ((NlsString) v).toString();
-} else {
-value = v;
-}
+
+PhoenixRelImplementor
+implementor = new PhoenixRelImplementorImpl(new 
RuntimeContextImpl());
--- End diff --

Looks like we need a "dummy" RuntimeContext for this kind of "dry run" 
implementor. I'll do this part when I commit it.


> Allow TRUE and FALSE to be used as literal constants
> 
>
> Key: PHOENIX-3264
> URL: https://issues.apache.org/jira/browse/PHOENIX-3264
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Eric Lomore
> Attachments: Sql2RelImplementation.png, SqlLiteral.png, 
> SqlNodeToRexConverterImpl.png, SqlOptionNode.png, objectdependencies.png, 
> objectdependencies2.png, stacktrace.png
>
>
> Phoenix supports TRUE and FALSE as boolean literals, but perhaps Calcite 
> doesn't? Looks like this is leading to a fair number of failures.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3264) Allow TRUE and FALSE to be used as literal constants

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533599#comment-15533599
 ] 

ASF GitHub Bot commented on PHOENIX-3264:
-

Github user maryannxue commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81201327
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
+
+SqlParserPos POS = SqlParserPos.ZERO;
+final SqlNodeList selectList =
+new SqlNodeList(
+Collections.singletonList(literal),
+SqlParserPos.ZERO);
+
+
+String sql = new SqlSelect(POS, SqlNodeList.EMPTY, selectList, 
null, null, null, null,
--- End diff --

Can we skip making a sql string and parsing again, coz you already have a 
SqlSelect node? We can go directly to planner.validate() and planner.rel(), 
right?


> Allow TRUE and FALSE to be used as literal constants
> 
>
> Key: PHOENIX-3264
> URL: https://issues.apache.org/jira/browse/PHOENIX-3264
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Eric Lomore
> Attachments: Sql2RelImplementation.png, SqlLiteral.png, 
> SqlNodeToRexConverterImpl.png, SqlOptionNode.png, objectdependencies.png, 
> objectdependencies2.png, stacktrace.png
>
>
> Phoenix supports TRUE and FALSE as boolean literals, but perhaps Calcite 
> doesn't? Looks like this is leading to a fair number of failures.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3264) Allow TRUE and FALSE to be used as literal constants

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533603#comment-15533603
 ] 

ASF GitHub Bot commented on PHOENIX-3264:
-

Github user maryannxue commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81200946
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
--- End diff --

Other convertXXX methods are to convert RexNode to Expression, so I'm 
thinking something like "convertSqlLiteral(...)" could be less confusing?


> Allow TRUE and FALSE to be used as literal constants
> 
>
> Key: PHOENIX-3264
> URL: https://issues.apache.org/jira/browse/PHOENIX-3264
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Eric Lomore
> Attachments: Sql2RelImplementation.png, SqlLiteral.png, 
> SqlNodeToRexConverterImpl.png, SqlOptionNode.png, objectdependencies.png, 
> objectdependencies2.png, stacktrace.png
>
>
> Phoenix supports TRUE and FALSE as boolean literals, but perhaps Calcite 
> doesn't? Looks like this is leading to a fair number of failures.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3264) Allow TRUE and FALSE to be used as literal constants

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533602#comment-15533602
 ] 

ASF GitHub Bot commented on PHOENIX-3264:
-

Github user maryannxue commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81201783
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
+
+SqlParserPos POS = SqlParserPos.ZERO;
+final SqlNodeList selectList =
+new SqlNodeList(
+Collections.singletonList(literal),
+SqlParserPos.ZERO);
+
+
+String sql = new SqlSelect(POS, SqlNodeList.EMPTY, selectList, 
null, null, null, null,
+SqlNodeList.EMPTY, null, null, null).toString();
+SqlNode sqlNode = planner.parse(sql);
+sqlNode = planner.validate(sqlNode);
+Project proj = (Project) (planner.rel(sqlNode).rel);
--- End diff --

Probably better to add an "assert" here to ensure the rel object is of 
Project class before casting it. Similarly, assert that this Project has only 
one expression for the following statement.


> Allow TRUE and FALSE to be used as literal constants
> 
>
> Key: PHOENIX-3264
> URL: https://issues.apache.org/jira/browse/PHOENIX-3264
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Eric Lomore
> Attachments: Sql2RelImplementation.png, SqlLiteral.png, 
> SqlNodeToRexConverterImpl.png, SqlOptionNode.png, objectdependencies.png, 
> objectdependencies2.png, stacktrace.png
>
>
> Phoenix supports TRUE and FALSE as boolean literals, but perhaps Calcite 
> doesn't? Looks like this is leading to a fair number of failures.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] phoenix pull request #212: PHOENIX-3264 Allow TRUE and FALSE to be used as l...

[maryannxue]

Github user maryannxue commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81201783
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
+
+SqlParserPos POS = SqlParserPos.ZERO;
+final SqlNodeList selectList =
+new SqlNodeList(
+Collections.singletonList(literal),
+SqlParserPos.ZERO);
+
+
+String sql = new SqlSelect(POS, SqlNodeList.EMPTY, selectList, 
null, null, null, null,
+SqlNodeList.EMPTY, null, null, null).toString();
+SqlNode sqlNode = planner.parse(sql);
+sqlNode = planner.validate(sqlNode);
+Project proj = (Project) (planner.rel(sqlNode).rel);
--- End diff --

Probably better to add an "assert" here to ensure the rel object is of 
Project class before casting it. Similarly, assert that this Project has only 
one expression for the following 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-3264) Allow TRUE and FALSE to be used as literal constants

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533601#comment-15533601
 ] 

ASF GitHub Bot commented on PHOENIX-3264:
-

Github user maryannxue commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81200246
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
--- End diff --

Since this method will be called once for each SQLLiteral, it might be 
better make these objects static members of CalciteUtils if possible.


> Allow TRUE and FALSE to be used as literal constants
> 
>
> Key: PHOENIX-3264
> URL: https://issues.apache.org/jira/browse/PHOENIX-3264
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Eric Lomore
> Attachments: Sql2RelImplementation.png, SqlLiteral.png, 
> SqlNodeToRexConverterImpl.png, SqlOptionNode.png, objectdependencies.png, 
> objectdependencies2.png, stacktrace.png
>
>
> Phoenix supports TRUE and FALSE as boolean literals, but perhaps Calcite 
> doesn't? Looks like this is leading to a fair number of failures.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3264) Allow TRUE and FALSE to be used as literal constants

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533604#comment-15533604
 ] 

ASF GitHub Bot commented on PHOENIX-3264:
-

Github user maryannxue commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81202299
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
+
+SqlParserPos POS = SqlParserPos.ZERO;
+final SqlNodeList selectList =
+new SqlNodeList(
+Collections.singletonList(literal),
+SqlParserPos.ZERO);
+
+
+String sql = new SqlSelect(POS, SqlNodeList.EMPTY, selectList, 
null, null, null, null,
+SqlNodeList.EMPTY, null, null, null).toString();
+SqlNode sqlNode = planner.parse(sql);
+sqlNode = planner.validate(sqlNode);
+Project proj = (Project) (planner.rel(sqlNode).rel);
+RexNode rex = proj.getChildExps().get(0);
+
+Expression e = CalciteUtils.toExpression(rex, implementor);
+ImmutableBytesWritable ptr = new ImmutableBytesWritable();
+e = ExpressionUtil.getConstantExpression(e, ptr);
+Object ret = e.getDataType().toObject(ptr);
+if(ret instanceof NlsString){
--- End diff --

Is this step necessary? I suppose no. But if yes, 
CalciteUtils.toExpression() must have not done its job correctly.


> Allow TRUE and FALSE to be used as literal constants
> 
>
> Key: PHOENIX-3264
> URL: https://issues.apache.org/jira/browse/PHOENIX-3264
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Eric Lomore
> Attachments: Sql2RelImplementation.png, SqlLiteral.png, 
> SqlNodeToRexConverterImpl.png, SqlOptionNode.png, objectdependencies.png, 
> objectdependencies2.png, stacktrace.png
>
>
> Phoenix supports TRUE and FALSE as boolean literals, but perhaps Calcite 
> doesn't? Looks like this is leading to a fair number of failures.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] phoenix pull request #212: PHOENIX-3264 Allow TRUE and FALSE to be used as l...

[maryannxue]

Github user maryannxue commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81202889
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
+
+SqlParserPos POS = SqlParserPos.ZERO;
+final SqlNodeList selectList =
+new SqlNodeList(
+Collections.singletonList(literal),
+SqlParserPos.ZERO);
+
+
+String sql = new SqlSelect(POS, SqlNodeList.EMPTY, selectList, 
null, null, null, null,
+SqlNodeList.EMPTY, null, null, null).toString();
+SqlNode sqlNode = planner.parse(sql);
+sqlNode = planner.validate(sqlNode);
+Project proj = (Project) (planner.rel(sqlNode).rel);
+RexNode rex = proj.getChildExps().get(0);
+
+Expression e = CalciteUtils.toExpression(rex, implementor);
+ImmutableBytesWritable ptr = new ImmutableBytesWritable();
+e = ExpressionUtil.getConstantExpression(e, ptr);
+Object ret = e.getDataType().toObject(ptr);
+if(ret instanceof NlsString){
+ret = ((NlsString) ret).toString();
+}
+return ret;
+}
+catch (Exception e){
+throw new RuntimeException("Could not convert literal to its 
object type: " + e);
--- End diff --

Normally you don't append the Exception itself to the end of the error 
message. You message should include the exact SqlLiteral it failed to convert 
and add the original Exception as inner exception.


---
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 #212: PHOENIX-3264 Allow TRUE and FALSE to be used as l...

[maryannxue]

Github user maryannxue commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81202299
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
+
+SqlParserPos POS = SqlParserPos.ZERO;
+final SqlNodeList selectList =
+new SqlNodeList(
+Collections.singletonList(literal),
+SqlParserPos.ZERO);
+
+
+String sql = new SqlSelect(POS, SqlNodeList.EMPTY, selectList, 
null, null, null, null,
+SqlNodeList.EMPTY, null, null, null).toString();
+SqlNode sqlNode = planner.parse(sql);
+sqlNode = planner.validate(sqlNode);
+Project proj = (Project) (planner.rel(sqlNode).rel);
+RexNode rex = proj.getChildExps().get(0);
+
+Expression e = CalciteUtils.toExpression(rex, implementor);
+ImmutableBytesWritable ptr = new ImmutableBytesWritable();
+e = ExpressionUtil.getConstantExpression(e, ptr);
+Object ret = e.getDataType().toObject(ptr);
+if(ret instanceof NlsString){
--- End diff --

Is this step necessary? I suppose no. But if yes, 
CalciteUtils.toExpression() must have not done its job correctly.


---
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 #212: PHOENIX-3264 Allow TRUE and FALSE to be used as l...

[maryannxue]

Github user maryannxue commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81201327
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
+
+SqlParserPos POS = SqlParserPos.ZERO;
+final SqlNodeList selectList =
+new SqlNodeList(
+Collections.singletonList(literal),
+SqlParserPos.ZERO);
+
+
+String sql = new SqlSelect(POS, SqlNodeList.EMPTY, selectList, 
null, null, null, null,
--- End diff --

Can we skip making a sql string and parsing again, coz you already have a 
SqlSelect node? We can go directly to planner.validate() and planner.rel(), 
right?


---
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 #212: PHOENIX-3264 Allow TRUE and FALSE to be used as l...

[maryannxue]

Github user maryannxue commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81203125
  
--- Diff: 
phoenix-core/src/main/java/org/apache/calcite/sql/SqlOptionNode.java ---
@@ -38,12 +41,10 @@ public SqlOptionNode(SqlParserPos pos, SqlIdentifier 
key, SqlLiteral literal) {
 familyName = key.names.get(0);
 propertyName = key.names.get(1);
 }
-final Object v = SqlLiteral.value(literal);
-if (v instanceof NlsString) {
-value = ((NlsString) v).toString();
-} else {
-value = v;
-}
+
+PhoenixRelImplementor
+implementor = new PhoenixRelImplementorImpl(new 
RuntimeContextImpl());
--- End diff --

Looks like we need a "dummy" RuntimeContext for this kind of "dry run" 
implementor. I'll do this part when I commit it.


---
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 #212: PHOENIX-3264 Allow TRUE and FALSE to be used as l...

[maryannxue]

Github user maryannxue commented on a diff in the pull request:

https://github.com/apache/phoenix/pull/212#discussion_r81200246
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/calcite/CalciteUtils.java ---
@@ -1036,4 +1048,40 @@ public Void visitCall(RexCall call) {
 return null;
 }
 }
+
+public static Object convertLiteral(SqlLiteral literal, 
PhoenixRelImplementor implementor) {
+try {
+final SchemaPlus rootSchema = 
Frameworks.createRootSchema(true);
+final FrameworkConfig config = Frameworks.newConfigBuilder()
+.parserConfig(SqlParser.Config.DEFAULT)
+.defaultSchema(rootSchema).build();
+Planner planner = Frameworks.getPlanner(config);
--- End diff --

Since this method will be called once for each SQLLiteral, it might be 
better make these objects static members of CalciteUtils if possible.


---
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.
---

Re: Comprehensive Guide for EXPLAIN

[James Taylor]

Yes, the EXPLAIN plan documentation is a section in the Tuning Guide that
would be super valuable to fill in. It'd be much appreciated if you could
move that forward.

Thanks,
James

On Thu, Sep 29, 2016 at 10:52 AM, Peter Conrad 
wrote:

> James:
>
> Should I work on putting together documentation on how to read an EXPLAIN
> plan? If so, what's the best way for me to get more information about it?
>
> Thanks,
> Peter
>
>
>
> Peter Conrad
>
> Staff Technical Writer: Infrastructure | salesforce.com
>
> Office: (415) 471-5265
>
>
> [image: http://www.salesforce.com/signature]
> 
>
> --
>
>
> On Mon, Sep 26, 2016 at 7:37 AM, James Taylor 
> wrote:
>
> > Hi Bernard,
> > No, unfortunately there's no documentation for our explain plan
> > (PHOENIX-1481).
> >
> > In your example, it's not fetching everything from the server. If it
> > fetches everything from the server it would say "FULL TABLE SCAN". In
> this
> > case, it's doing a "RANGE SCAN" between these two key ranges:
> >
> > [0,'2016-08-27 06:27:17.719'] - [0,*]
> >
> > I suspect your TEST.TABLE is salted, as the [0] above would represent the
> > salt byte. Maybe you're using a slightly older version of Phoenix too,
> > because AFAIR we show the salt bucket differently in later version. The
> > date is based on now() - 30. So the range is everything greater than that
> > date.
> >
> > The 1-CHUNK PARALLEL 1-WAY tells you how much parallelization the client
> is
> > doing and over how many scans a merge sort is being done over. Your table
> > must be only one region, or the
> >
> > Since you're only selecting columns contained in the row key, Phoenix is
> > pushing a FirstKeyOnlyFilter, that's what this represents:
> >
> > SERVER FILTER BY FIRST KEY ONLY
> >
> > Then, since you're doing an ungrouped aggregation, this tells you that
> the
> > aggregation is happening on the server side:
> >
> > SERVER AGGREGATE INTO SINGLE ROW
> >
> > Assuming your table is salted, the scan will be run on each salt bucket
> and
> > then the one row we get back from these scans will be summed together to
> > calculate the final COUNT(1).
> >
> > HTH. Thanks,
> >
> > James
> >
> > On Sun, Sep 25, 2016 at 11:36 PM, Bernard Quizon  > stellarloyalty.com> wrote:
> >
> > > Hi,
> > >
> > >
> > > I know explain statement results are relatively easy to understand but
> is
> > > there a comprehensive guide for it?
> > >
> > >
> > > 0: jdbc:phoenix:localhost> explain select count(1) from test.table
> where
> > > insert_ts > now() - 30;
> > >
> > > *+--+*
> > >
> > > *| **  PLAN  ** |*
> > >
> > > *+--+*
> > >
> > > *| *CLIENT 1-CHUNK PARALLEL 1-WAY RANGE SCAN OVER TEST.TABLE
> > [0,'2016-08-27
> > > 06:27:17.719'] - [0,*]* |*
> > >
> > > *| *SERVER FILTER BY FIRST KEY ONLY * |*
> > >
> > > *| *SERVER AGGREGATE INTO SINGLE ROW* |*
> > >
> > > *+--+ *
> > >
> > >
> > >
> > > Like for example in the query above from what I understand, it fetches
> > > everything from the server then applies the key range on client side.
> > >
> > > But I’m thinking isn’t it less expensive if key range was already
> applied
> > > on the server so less data will be transmitted, thus saving network and
> > > memory overhead.
> > >
> > > Or is my understanding wrong?
> > >
> > >
> > > Thanks
> > >
> >
>

[jira] [Commented] (PHOENIX-3298) Create Table: Single column primary key may not be null

[James Taylor (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533579#comment-15533579
 ] 

James Taylor commented on PHOENIX-3298:
---

The ColumnDef object in Phoenix declares isNull as Boolean:
{code}
public class ColumnDef {
private final ColumnName columnDefName;
private final PDataType dataType;
private final Boolean isNull;
private final Integer maxLength;
private final Integer scale;
private boolean isPK;
private final SortOrder sortOrder;
private final boolean isArray;
private final Integer arrSize;
private final String expressionStr;
private final boolean isRowTimestamp;

ColumnDef(ColumnName columnDefName, String sqlTypeName, boolean isArray, 
Integer arrSize, Boolean isNull, Integer maxLength,
Integer scale, boolean isPK, SortOrder sortOrder, String 
expressionStr, boolean isRowTimestamp) {
{code}

We've got the following code in MetaDataClient that will flag the problematic 
declaration:
{code}
if (isPK && !addingToPK && pkConstraint.getColumnNames().size() <= 
1) {
if (def.isNull() && def.isNullSet()) {
throw new 
SQLExceptionInfo.Builder(SQLExceptionCode.SINGLE_PK_MAY_NOT_BE_NULL)
.setColumnName(columnName).build().buildException();
}
isNull = false;
}
{code}

Can we declare the isNull as Boolean in parserImpls.ftl and leave it as null if 
not set? Is SqlColumnDefNode derived from ColumnDef or does a translation occur 
to it? Either way, if the ColumnDef isNull Boolean is set appropriately (null, 
true, or false), I don't think there'll be an issue.

> Create Table: Single column primary key may not be null
> ---
>
> Key: PHOENIX-3298
> URL: https://issues.apache.org/jira/browse/PHOENIX-3298
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: Eric Lomore
>Assignee: Eric Lomore
> Attachments: PHOENIX-3298-WIP
>
>
> Create table statements with a single column currently must have "NOT NULL" 
> identifier to pass tests.
> Running this code results in failure
> {code}CREATE TABLE t (k VARCHAR PRIMARY KEY DESC){code}
> While this allows tests to pass
> {code}CREATE TABLE t (k VARCHAR NOT NULL PRIMARY KEY DESC){code}
> Must either enforce the not null condition and update test cases, or apply a 
> fix.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3298) Create Table: Single column primary key may not be null

[Eric Lomore (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533521#comment-15533521
 ] 

Eric Lomore commented on PHOENIX-3298:
--

Quick summary of what I was talking about:

During grammar execution, we parse nodes as either Nullable or Not Nullable. If 
no option is stated, then by default, Nullable. No information is preserved on 
whether it was set by default or explicitly.

Once all ColumnDefs are created, and ColumnDefInPkConstraints are created, we 
need to identify the case where there is a single PK column node, and it was 
set to Nullable by default. 

The issue arises in passing this "default"  information down. Hence far, my 2 
ideas were to change the primitive isNull field to a Boolean isNull field, or 
to introduce a new field called implicitlyNull. 
Both of these changes require large changes to the underlying Phoenix code, 
which would cause changes to PhoenixSQL.g which is not what we want because 
this functionality works in Phoenix.
The idea of solving this in the grammar execution doesn't work either since the 
ColumnDefs are constructed long before we have any info on PKConstraints, which 
aren't processed until MetaDataClient.java.

See the attached patch that would convert "Nullable" to "Not Nullable" for ANY 
single column primary key (not just those implicitly set).

The relevant grammar code:

{code:java|title=parserImpls.ftl}
SqlColumnDefNode ColumnDef() :
{
SqlIdentifier columnName;
SqlDataTypeNode dataType;
boolean isNull = true;
boolean isPk = false;
SortOrder sortOrder = SortOrder.getDefault();
boolean isRowTimestamp = false;
SqlParserPos pos;
}
{
columnName = DualIdentifier()
dataType = PhoenixDataType()
[
 
{isNull = false;}
|

{isNull = true;}
]
[
 
{isPk = true;}
]
[

{sortOrder = SortOrder.ASC;}
|

{sortOrder = SortOrder.DESC;}
]
[

{isRowTimestamp = true;}
]
{
pos = columnName.getParserPosition().plus(getPos());
return new SqlColumnDefNode(pos, columnName, dataType, isNull, isPk, 
sortOrder, null, isRowTimestamp);
}
}
{code}

> Create Table: Single column primary key may not be null
> ---
>
> Key: PHOENIX-3298
> URL: https://issues.apache.org/jira/browse/PHOENIX-3298
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: Eric Lomore
>Assignee: Eric Lomore
> Attachments: PHOENIX-3298-WIP
>
>
> Create table statements with a single column currently must have "NOT NULL" 
> identifier to pass tests.
> Running this code results in failure
> {code}CREATE TABLE t (k VARCHAR PRIMARY KEY DESC){code}
> While this allows tests to pass
> {code}CREATE TABLE t (k VARCHAR NOT NULL PRIMARY KEY DESC){code}
> Must either enforce the not null condition and update test cases, or apply a 
> fix.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3298) Create Table: Single column primary key may not be null

[Eric Lomore (JIRA)]

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

Eric Lomore updated PHOENIX-3298:
-
Attachment: PHOENIX-3298-WIP

PHOENIX-3298 WIP Converts all single primary key columns to not nullable


> Create Table: Single column primary key may not be null
> ---
>
> Key: PHOENIX-3298
> URL: https://issues.apache.org/jira/browse/PHOENIX-3298
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: Eric Lomore
>Assignee: Eric Lomore
> Attachments: PHOENIX-3298-WIP
>
>
> Create table statements with a single column currently must have "NOT NULL" 
> identifier to pass tests.
> Running this code results in failure
> {code}CREATE TABLE t (k VARCHAR PRIMARY KEY DESC){code}
> While this allows tests to pass
> {code}CREATE TABLE t (k VARCHAR NOT NULL PRIMARY KEY DESC){code}
> Must either enforce the not null condition and update test cases, or apply a 
> fix.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Comprehensive Guide for EXPLAIN

[Peter Conrad]

James:

Should I work on putting together documentation on how to read an EXPLAIN
plan? If so, what's the best way for me to get more information about it?

Thanks,
Peter



Peter Conrad

Staff Technical Writer: Infrastructure | salesforce.com

Office: (415) 471-5265


[image: http://www.salesforce.com/signature]


--


On Mon, Sep 26, 2016 at 7:37 AM, James Taylor 
wrote:

> Hi Bernard,
> No, unfortunately there's no documentation for our explain plan
> (PHOENIX-1481).
>
> In your example, it's not fetching everything from the server. If it
> fetches everything from the server it would say "FULL TABLE SCAN". In this
> case, it's doing a "RANGE SCAN" between these two key ranges:
>
> [0,'2016-08-27 06:27:17.719'] - [0,*]
>
> I suspect your TEST.TABLE is salted, as the [0] above would represent the
> salt byte. Maybe you're using a slightly older version of Phoenix too,
> because AFAIR we show the salt bucket differently in later version. The
> date is based on now() - 30. So the range is everything greater than that
> date.
>
> The 1-CHUNK PARALLEL 1-WAY tells you how much parallelization the client is
> doing and over how many scans a merge sort is being done over. Your table
> must be only one region, or the
>
> Since you're only selecting columns contained in the row key, Phoenix is
> pushing a FirstKeyOnlyFilter, that's what this represents:
>
> SERVER FILTER BY FIRST KEY ONLY
>
> Then, since you're doing an ungrouped aggregation, this tells you that the
> aggregation is happening on the server side:
>
> SERVER AGGREGATE INTO SINGLE ROW
>
> Assuming your table is salted, the scan will be run on each salt bucket and
> then the one row we get back from these scans will be summed together to
> calculate the final COUNT(1).
>
> HTH. Thanks,
>
> James
>
> On Sun, Sep 25, 2016 at 11:36 PM, Bernard Quizon  stellarloyalty.com> wrote:
>
> > Hi,
> >
> >
> > I know explain statement results are relatively easy to understand but is
> > there a comprehensive guide for it?
> >
> >
> > 0: jdbc:phoenix:localhost> explain select count(1) from test.table where
> > insert_ts > now() - 30;
> >
> > *+--+*
> >
> > *| **  PLAN  ** |*
> >
> > *+--+*
> >
> > *| *CLIENT 1-CHUNK PARALLEL 1-WAY RANGE SCAN OVER TEST.TABLE
> [0,'2016-08-27
> > 06:27:17.719'] - [0,*]* |*
> >
> > *| *SERVER FILTER BY FIRST KEY ONLY * |*
> >
> > *| *SERVER AGGREGATE INTO SINGLE ROW* |*
> >
> > *+--+ *
> >
> >
> >
> > Like for example in the query above from what I understand, it fetches
> > everything from the server then applies the key range on client side.
> >
> > But I’m thinking isn’t it less expensive if key range was already applied
> > on the server so less data will be transmitted, thus saving network and
> > memory overhead.
> >
> > Or is my understanding wrong?
> >
> >
> > Thanks
> >
>

[jira] [Commented] (PHOENIX-3254) IndexId Sequence is incremented even if index exists already.

[Ankit Singhal (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533447#comment-15533447
 ] 

Ankit Singhal commented on PHOENIX-3254:


Thanks [~jamestaylor] & [~rajesh23] for review.

[~jamestaylor], FYI, Test 
(./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.tx.TransactionIT)
 seems to be flapping.

Committed a latest patch to master and 4.x branches.

> IndexId Sequence is incremented even if index exists already.
> -
>
> Key: PHOENIX-3254
> URL: https://issues.apache.org/jira/browse/PHOENIX-3254
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3254.patch, PHOENIX-3254_v1.patch, 
> PHOENIX-3254_wip.patch
>
>
> As we are incrementing sequence at the client even if we are not going to 
> create a index (in case index already exists and user is using CREATE INDEX 
> IF NOT EXISTS) or DDL failed in later stage(due to parent table not found or 
> something).
> If this keeps on happening then user may reach the limit of Short.MAX_VALUE 
> and TOO_MANY_INDEXES exception will be thrown if user tries to create a new 
> index.
> To prevent, this we should increment sequences when we are about to create a 
> index at server.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3242) Support CREATE OR REPLACE FUNCTION in Phoenix-Calcite Integration

[Rajeshbabu Chintaguntla (JIRA)]

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

Rajeshbabu Chintaguntla updated PHOENIX-3242:
-
Attachment: PHOENIX-3242_select-wip.patch

[~maryannxue] Here is wip patch using UDF function in select query.
You can run UserDefinedFunctionsIT#testUDFsWithMultipleConnections to check 
testing where select query using UDF function is failing.
Here are couple of changes I have done other than DDL:
- In PhoenixScheam#getFunctions tried to load the class and create 
SchalarFunctionImpl - which is not correct but just tried to reach 
PhoenixAbstractProject to translate which fail with exception.


> Support CREATE OR REPLACE FUNCTION in Phoenix-Calcite Integration
> -
>
> Key: PHOENIX-3242
> URL: https://issues.apache.org/jira/browse/PHOENIX-3242
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
>  Labels: calcite
> Attachments: PHOENIX-3242-wip.patch, PHOENIX-3242_select-wip.patch, 
> PHOENIX-3242_v1.patch, PHOENIX-3242_v2.patch, PHOENIX-3242_v3.patch, 
> PHOENIX-3242_v4.patch, PHOENIX-3242_v5.patch, PHOENIX-3242_v6.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3264) Allow TRUE and FALSE to be used as literal constants

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533016#comment-15533016
 ] 

ASF GitHub Bot commented on PHOENIX-3264:
-

GitHub user lomoree opened a pull request:

https://github.com/apache/phoenix/pull/212

PHOENIX-3264 Allow TRUE and FALSE to be used as literal constants



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bloomberg/phoenix calcite

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/phoenix/pull/212.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #212


commit fb59ed04b151fd8e7533cf5c99c70118a697de77
Author: Eric 
Date:   2016-09-28T17:56:29Z

PHOENIX-3264 Allow TRUE and FALSE to be used as literal constants




> Allow TRUE and FALSE to be used as literal constants
> 
>
> Key: PHOENIX-3264
> URL: https://issues.apache.org/jira/browse/PHOENIX-3264
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Eric Lomore
> Attachments: Sql2RelImplementation.png, SqlLiteral.png, 
> SqlNodeToRexConverterImpl.png, SqlOptionNode.png, objectdependencies.png, 
> objectdependencies2.png, stacktrace.png
>
>
> Phoenix supports TRUE and FALSE as boolean literals, but perhaps Calcite 
> doesn't? Looks like this is leading to a fair number of failures.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] phoenix pull request #212: PHOENIX-3264 Allow TRUE and FALSE to be used as l...

[lomoree]

GitHub user lomoree opened a pull request:

https://github.com/apache/phoenix/pull/212

PHOENIX-3264 Allow TRUE and FALSE to be used as literal constants



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bloomberg/phoenix calcite

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/phoenix/pull/212.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #212


commit fb59ed04b151fd8e7533cf5c99c70118a697de77
Author: Eric 
Date:   2016-09-28T17:56:29Z

PHOENIX-3264 Allow TRUE and FALSE to be used as literal constants




---
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-3254) IndexId Sequence is incremented even if index exists already.

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15532880#comment-15532880
 ] 

Hadoop QA commented on PHOENIX-3254:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12830885/PHOENIX-3254_v1.patch
  against master branch at commit 15a2f9a625dc9a76fd07cae82e81d8ec1d79d622.
  ATTACHMENT ID: 12830885

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 6 new 
or modified tests.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:red}-1 javadoc{color}.  The javadoc tool appears to have generated 
38 warning messages.

{color:red}-1 release audit{color}.  The applied patch generated 1 release 
audit warnings (more than the master's current 0 warnings).

{color:red}-1 lineLengths{color}.  The patch introduces the following lines 
longer than 100:
+verifySequenceValue(isNamespaceEnabled? "a" : null, sequenceNameA, 
sequenceSchemaName, -32767);
+verifySequenceValue(isNamespaceEnabled? "b" : null, sequenceNameB, 
sequenceSchemaName, -32767);
+conn1.createStatement().execute("CREATE INDEX " + indexName + "_2 ON " 
+ viewName + " (v1)");
+String tenantIdStr = tenantIdBytes.length == 0 ? null : 
Bytes.toString(tenantIdBytes);
+try (PhoenixConnection connection = 
DriverManager.getConnection(MetaDataUtil.getJdbcUrl(env), props)
+int nSequenceSaltBuckets = 
connection.getQueryServices().getSequenceSaltBuckets();
+SequenceKey key = 
MetaDataUtil.getViewIndexSequenceKey(tenantIdStr, physicalName,
+// TODO Review Earlier sequence was created at 
(SCN-1/LATEST_TIMESTAMP) and incremented at the
+// use always LATEST_TIMESTAMP to avoid seeing wrong 
sequence values by different connection
+
connection.getQueryServices().createSequence(key.getTenantId(), 
key.getSchemaName(),

{color:green}+1 core tests{color}.  The patch passed unit tests in .

Test results: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/607//testReport/
Release audit warnings: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/607//artifact/patchprocess/patchReleaseAuditWarnings.txt
Javadoc warnings: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/607//artifact/patchprocess/patchJavadocWarnings.txt
Console output: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/607//console

This message is automatically generated.

> IndexId Sequence is incremented even if index exists already.
> -
>
> Key: PHOENIX-3254
> URL: https://issues.apache.org/jira/browse/PHOENIX-3254
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3254.patch, PHOENIX-3254_v1.patch, 
> PHOENIX-3254_wip.patch
>
>
> As we are incrementing sequence at the client even if we are not going to 
> create a index (in case index already exists and user is using CREATE INDEX 
> IF NOT EXISTS) or DDL failed in later stage(due to parent table not found or 
> something).
> If this keeps on happening then user may reach the limit of Short.MAX_VALUE 
> and TOO_MANY_INDEXES exception will be thrown if user tries to create a new 
> index.
> To prevent, this we should increment sequences when we are about to create a 
> index at server.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3254) IndexId Sequence is incremented even if index exists already.

[Ankit Singhal (JIRA)]

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

Ankit Singhal updated PHOENIX-3254:
---
Attachment: PHOENIX-3254_v1.patch

> IndexId Sequence is incremented even if index exists already.
> -
>
> Key: PHOENIX-3254
> URL: https://issues.apache.org/jira/browse/PHOENIX-3254
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3254.patch, PHOENIX-3254_v1.patch, 
> PHOENIX-3254_wip.patch
>
>
> As we are incrementing sequence at the client even if we are not going to 
> create a index (in case index already exists and user is using CREATE INDEX 
> IF NOT EXISTS) or DDL failed in later stage(due to parent table not found or 
> something).
> If this keeps on happening then user may reach the limit of Short.MAX_VALUE 
> and TOO_MANY_INDEXES exception will be thrown if user tries to create a new 
> index.
> To prevent, this we should increment sequences when we are about to create a 
> index at server.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3254) IndexId Sequence is incremented even if index exists already.

[Ankit Singhal (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15532734#comment-15532734
 ] 

Ankit Singhal commented on PHOENIX-3254:


{code}
-1 core tests. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.tx.TransactionIT
{code}
Not sure, It is related to this.

Running QA bot again with v1.

> IndexId Sequence is incremented even if index exists already.
> -
>
> Key: PHOENIX-3254
> URL: https://issues.apache.org/jira/browse/PHOENIX-3254
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3254.patch, PHOENIX-3254_v1.patch, 
> PHOENIX-3254_wip.patch
>
>
> As we are incrementing sequence at the client even if we are not going to 
> create a index (in case index already exists and user is using CREATE INDEX 
> IF NOT EXISTS) or DDL failed in later stage(due to parent table not found or 
> something).
> If this keeps on happening then user may reach the limit of Short.MAX_VALUE 
> and TOO_MANY_INDEXES exception will be thrown if user tries to create a new 
> index.
> To prevent, this we should increment sequences when we are about to create a 
> index at server.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3331) Bug in calculating minDisabledTimestamp for a batch

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15532628#comment-15532628
 ] 

Hudson commented on PHOENIX-3331:
-

SUCCESS: Integrated in Jenkins build Phoenix-4.8-HBase-1.2 #32 (See 
[https://builds.apache.org/job/Phoenix-4.8-HBase-1.2/32/])
PHOENIX-3331 Bug in calculating minDisabledTimestamp for a batch 
(ankitsinghal59: rev 468ca2b93de0a865216e017be0edfbe599ebe6f0)
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/index/PhoenixIndexFailurePolicy.java


> Bug in calculating minDisabledTimestamp for a batch
> ---
>
> Key: PHOENIX-3331
> URL: https://issues.apache.org/jira/browse/PHOENIX-3331
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
> Fix For: 4.9.0, 4.8.2
>
> Attachments: PHOENIX-3331.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3331) Bug in calculating minDisabledTimestamp for a batch

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15532581#comment-15532581
 ] 

Hudson commented on PHOENIX-3331:
-

FAILURE: Integrated in Jenkins build Phoenix-master #1423 (See 
[https://builds.apache.org/job/Phoenix-master/1423/])
PHOENIX-3331 Bug in calculating minDisabledTimestamp for a batch 
(ankitsinghal59: rev 6f9cca433d8acad980d98f3c0e31dea1d7e4e743)
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/index/PhoenixIndexFailurePolicy.java


> Bug in calculating minDisabledTimestamp for a batch
> ---
>
> Key: PHOENIX-3331
> URL: https://issues.apache.org/jira/browse/PHOENIX-3331
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
> Fix For: 4.9.0, 4.8.2
>
> Attachments: PHOENIX-3331.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3221) "LOCAL" keyword is not adhered for "phoenix.query.dateFormatTimeZone"

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15532582#comment-15532582
 ] 

Hudson commented on PHOENIX-3221:
-

FAILURE: Integrated in Jenkins build Phoenix-master #1423 (See 
[https://builds.apache.org/job/Phoenix-master/1423/])
PHOENIX-3221 'LOCAL' keyword is not adhered for (ankitsinghal59: rev 
15a2f9a625dc9a76fd07cae82e81d8ec1d79d622)
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/compile/StatementContext.java
* (edit) phoenix-core/src/main/java/org/apache/phoenix/util/DateUtil.java


> "LOCAL" keyword is not adhered for "phoenix.query.dateFormatTimeZone"
> -
>
> Key: PHOENIX-3221
> URL: https://issues.apache.org/jira/browse/PHOENIX-3221
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3221.patch
>
>
> Currently, it is falling back to GMT.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3211) Support running UPSERT SELECT asynchronously

[Loknath Priyatham Teja Singamsetty (JIRA)]

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

Loknath Priyatham Teja Singamsetty  updated PHOENIX-3211:
-
Fix Version/s: 4.9.0

> Support running UPSERT SELECT asynchronously
> 
>
> Key: PHOENIX-3211
> URL: https://issues.apache.org/jira/browse/PHOENIX-3211
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: James Taylor
>Assignee: Loknath Priyatham Teja Singamsetty 
> Fix For: 4.9.0
>
>
> We have support for creating indexes asynchronously. We should add the 
> ability to run an UPSERT SELECT asynchronously too for very large tables.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3254) IndexId Sequence is incremented even if index exists already.

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15532515#comment-15532515
 ] 

Hadoop QA commented on PHOENIX-3254:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12830285/PHOENIX-3254.patch
  against master branch at commit 15a2f9a625dc9a76fd07cae82e81d8ec1d79d622.
  ATTACHMENT ID: 12830285

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 6 new 
or modified tests.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:red}-1 javadoc{color}.  The javadoc tool appears to have generated 
38 warning messages.

{color:red}-1 release audit{color}.  The applied patch generated 1 release 
audit warnings (more than the master's current 0 warnings).

{color:red}-1 lineLengths{color}.  The patch introduces the following lines 
longer than 100:
+verifySequenceValue(isNamespaceEnabled? "a" : null, sequenceNameA, 
sequenceSchemaName, -32767);
+verifySequenceValue(isNamespaceEnabled? "b" : null, sequenceNameB, 
sequenceSchemaName, -32767);
+conn1.createStatement().execute("CREATE INDEX " + indexName + "_2 ON " 
+ viewName + " (v1)");
+String tenantIdStr = tenantIdBytes.length == 0 ? null : 
Bytes.toString(tenantIdBytes);
+try (PhoenixConnection connection = 
DriverManager.getConnection(MetaDataUtil.getJdbcUrl(env), 
props).unwrap(PhoenixConnection.class)){
+int nSequenceSaltBuckets = 
connection.getQueryServices().getSequenceSaltBuckets();
+SequenceKey key = 
MetaDataUtil.getViewIndexSequenceKey(tenantIdStr, physicalName,
+// TODO Review Earlier sequence was created at 
(SCN-1/LATEST_TIMESTAMP) and incremented at the client 
max(SCN,dataTable.getTimestamp), but it seems we should
+// use always LATEST_TIMESTAMP to avoid seeing wrong 
sequence values by different connection having SCN
+
connection.getQueryServices().createSequence(key.getTenantId(), 
key.getSchemaName(), key.getSequenceName(),

 {color:red}-1 core tests{color}.  The patch failed these unit tests:
 
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.tx.TransactionIT

Test results: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/606//testReport/
Release audit warnings: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/606//artifact/patchprocess/patchReleaseAuditWarnings.txt
Javadoc warnings: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/606//artifact/patchprocess/patchJavadocWarnings.txt
Console output: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/606//console

This message is automatically generated.

> IndexId Sequence is incremented even if index exists already.
> -
>
> Key: PHOENIX-3254
> URL: https://issues.apache.org/jira/browse/PHOENIX-3254
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3254.patch, PHOENIX-3254_wip.patch
>
>
> As we are incrementing sequence at the client even if we are not going to 
> create a index (in case index already exists and user is using CREATE INDEX 
> IF NOT EXISTS) or DDL failed in later stage(due to parent table not found or 
> something).
> If this keeps on happening then user may reach the limit of Short.MAX_VALUE 
> and TOO_MANY_INDEXES exception will be thrown if user tries to create a new 
> index.
> To prevent, this we should increment sequences when we are about to create a 
> index at server.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-3211) Support running UPSERT SELECT asynchronously

[Loknath Priyatham Teja Singamsetty (JIRA)]

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

Loknath Priyatham Teja Singamsetty  updated PHOENIX-3211:
-
Issue Type: New Feature  (was: Bug)

> Support running UPSERT SELECT asynchronously
> 
>
> Key: PHOENIX-3211
> URL: https://issues.apache.org/jira/browse/PHOENIX-3211
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: James Taylor
>Assignee: Loknath Priyatham Teja Singamsetty 
>
> We have support for creating indexes asynchronously. We should add the 
> ability to run an UPSERT SELECT asynchronously too for very large tables.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3331) Bug in calculating minDisabledTimestamp for a batch

[Ankit Singhal (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15532365#comment-15532365
 ] 

Ankit Singhal commented on PHOENIX-3331:


committed to 4.8,4.x and master branches.

> Bug in calculating minDisabledTimestamp for a batch
> ---
>
> Key: PHOENIX-3331
> URL: https://issues.apache.org/jira/browse/PHOENIX-3331
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
> Fix For: 4.9.0, 4.8.2
>
> Attachments: PHOENIX-3331.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-3221) "LOCAL" keyword is not adhered for "phoenix.query.dateFormatTimeZone"

[Ankit Singhal (JIRA)]

[ 
https://issues.apache.org/jira/browse/PHOENIX-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15532359#comment-15532359
 ] 

Ankit Singhal commented on PHOENIX-3221:


Thanks [~rajesh23], committed to master and 4.x branches.

> "LOCAL" keyword is not adhered for "phoenix.query.dateFormatTimeZone"
> -
>
> Key: PHOENIX-3221
> URL: https://issues.apache.org/jira/browse/PHOENIX-3221
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3221.patch
>
>
> Currently, it is falling back to GMT.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)