[jira] [Updated] (PHOENIX-5961) More guide on how to start QueryServer

[Jingtao Wu (Jira)]

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

Jingtao Wu updated PHOENIX-5961:

Description: 
It would be good to have more guide on how to set up a working environment for 
phoenix-queryserver in README. For things like
 # How to get Phoenix client jar file
 # Which directory to put Phoenix client jar file so that queryserver.py are 
able to find it. 
 # Phoenix and Hbase versions that are supported and compatible
 # maybe attach this page for reference [https://phoenix.apache.org/server.html]

Also I am not able to execute this command from README 

{{}}
{code:java}
$ mvn package -Dpackage.phoenix.client -Dphoenix.version=5.1.0-SNAPSHOT 
-Dphoenix.hbase.classifier=hbase-2.2{code}
{{}}

I see this error when trying to execute that command

{{}}
{code:java}
[ERROR] Failed to execute goal on project queryserver: Could not resolve 
dependencies for project org.apache.phoenix:queryserver:jar:1.0.0-SNAPSHOT: 
Failure to find org.apache.phoenix:phoenix-core:jar:5.1.0-SNAPSHOT in 
https://repository.apache.org/snapshots was cached in the local repository, 
resolution will not be reattempted until the update interval of 
apache.snapshots has elapsed or updates are forced -> [Help 1] {code}
{{}}

{{}}

  was:
It would be good to have more guide on how to set up a working environment for 
phoenix-queryserver in README. For things like
 # How to get Phoenix client jar file
 # Which directory to put Phoenix client jar file so that queryserver.py are 
able to find it. 
 # Phoenix and Hbase versions that are supported and compatible
 # maybe attach this page for reference [https://phoenix.apache.org/server.html]


> More guide on how to start QueryServer
> --
>
> Key: PHOENIX-5961
> URL: https://issues.apache.org/jira/browse/PHOENIX-5961
> Project: Phoenix
>  Issue Type: Wish
>  Components: queryserver
>Affects Versions: queryserver-1.0.0
>Reporter: Jingtao Wu
>Priority: Minor
>
> It would be good to have more guide on how to set up a working environment 
> for phoenix-queryserver in README. For things like
>  # How to get Phoenix client jar file
>  # Which directory to put Phoenix client jar file so that queryserver.py are 
> able to find it. 
>  # Phoenix and Hbase versions that are supported and compatible
>  # maybe attach this page for reference 
> [https://phoenix.apache.org/server.html]
> Also I am not able to execute this command from README 
> {{}}
> {code:java}
> $ mvn package -Dpackage.phoenix.client -Dphoenix.version=5.1.0-SNAPSHOT 
> -Dphoenix.hbase.classifier=hbase-2.2{code}
> {{}}
> I see this error when trying to execute that command
> {{}}
> {code:java}
> [ERROR] Failed to execute goal on project queryserver: Could not resolve 
> dependencies for project org.apache.phoenix:queryserver:jar:1.0.0-SNAPSHOT: 
> Failure to find org.apache.phoenix:phoenix-core:jar:5.1.0-SNAPSHOT in 
> https://repository.apache.org/snapshots was cached in the local repository, 
> resolution will not be reattempted until the update interval of 
> apache.snapshots has elapsed or updates are forced -> [Help 1] {code}
> {{}}
> {{}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5961) More guide on how to start QueryServer

[Jingtao Wu (Jira)]

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

Jingtao Wu updated PHOENIX-5961:

Description: 
It would be good to have more guide on how to set up a working environment for 
phoenix-queryserver in README. For things like
 # How to get Phoenix client jar file
 # Which directory to put Phoenix client jar file so that queryserver.py are 
able to find it. 
 # Phoenix and Hbase versions that are supported and compatible
 # maybe attach this page for reference [https://phoenix.apache.org/server.html]

Also I am not able to execute this command from README 
{code:java}
$ mvn package -Dpackage.phoenix.client -Dphoenix.version=5.1.0-SNAPSHOT 
-Dphoenix.hbase.classifier=hbase-2.2{code}
I see this error when trying to execute that command
{code:java}
[ERROR] Failed to execute goal on project queryserver: Could not resolve 
dependencies for project org.apache.phoenix:queryserver:jar:1.0.0-SNAPSHOT: 
Failure to find org.apache.phoenix:phoenix-core:jar:5.1.0-SNAPSHOT in 
https://repository.apache.org/snapshots was cached in the local repository, 
resolution will not be reattempted until the update interval of 
apache.snapshots has elapsed or updates are forced -> [Help 1] {code}
 

  was:
It would be good to have more guide on how to set up a working environment for 
phoenix-queryserver in README. For things like
 # How to get Phoenix client jar file
 # Which directory to put Phoenix client jar file so that queryserver.py are 
able to find it. 
 # Phoenix and Hbase versions that are supported and compatible
 # maybe attach this page for reference [https://phoenix.apache.org/server.html]

Also I am not able to execute this command from README 

{{}}
{code:java}
$ mvn package -Dpackage.phoenix.client -Dphoenix.version=5.1.0-SNAPSHOT 
-Dphoenix.hbase.classifier=hbase-2.2{code}
{{}}

I see this error when trying to execute that command

{{}}
{code:java}
[ERROR] Failed to execute goal on project queryserver: Could not resolve 
dependencies for project org.apache.phoenix:queryserver:jar:1.0.0-SNAPSHOT: 
Failure to find org.apache.phoenix:phoenix-core:jar:5.1.0-SNAPSHOT in 
https://repository.apache.org/snapshots was cached in the local repository, 
resolution will not be reattempted until the update interval of 
apache.snapshots has elapsed or updates are forced -> [Help 1] {code}
{{}}

{{}}


> More guide on how to start QueryServer
> --
>
> Key: PHOENIX-5961
> URL: https://issues.apache.org/jira/browse/PHOENIX-5961
> Project: Phoenix
>  Issue Type: Wish
>  Components: queryserver
>Affects Versions: queryserver-1.0.0
>Reporter: Jingtao Wu
>Priority: Minor
>
> It would be good to have more guide on how to set up a working environment 
> for phoenix-queryserver in README. For things like
>  # How to get Phoenix client jar file
>  # Which directory to put Phoenix client jar file so that queryserver.py are 
> able to find it. 
>  # Phoenix and Hbase versions that are supported and compatible
>  # maybe attach this page for reference 
> [https://phoenix.apache.org/server.html]
> Also I am not able to execute this command from README 
> {code:java}
> $ mvn package -Dpackage.phoenix.client -Dphoenix.version=5.1.0-SNAPSHOT 
> -Dphoenix.hbase.classifier=hbase-2.2{code}
> I see this error when trying to execute that command
> {code:java}
> [ERROR] Failed to execute goal on project queryserver: Could not resolve 
> dependencies for project org.apache.phoenix:queryserver:jar:1.0.0-SNAPSHOT: 
> Failure to find org.apache.phoenix:phoenix-core:jar:5.1.0-SNAPSHOT in 
> https://repository.apache.org/snapshots was cached in the local repository, 
> resolution will not be reattempted until the update interval of 
> apache.snapshots has elapsed or updates are forced -> [Help 1] {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5959) python scripts not working for phoenix-queryserver

[Jingtao Wu (Jira)]

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

Jingtao Wu updated PHOENIX-5959:

Description: 
queryserver.py currently cannot properly start queryserver for following two 
reasons. 

After phoenix-queryserver is taken out from phoenix, thin client jar and 
queryserver jar have been renamed from 
phoenix-*thin-client.jar/phoenix*queryserver.jar to 
queryserver-client*SNAPSHOT.jar/queryserver*.jar, but phoenix_utils.py is still 
looking for the old jar files.  

Also queryserver-1.0.0-SNAPSHOT.jar probably does not contains all the 
dependency to start queryserver. I ran into a NoClassDefFoundError after I 
corrected the jar file names in phoenix_util.py. I had to modify the pom file 
to package all dependencies into the jar file in order to start queryserver 
properly. 

  was:
queryserver.py currently cannot properly start queryserver for following two 
reasons. 

After phoenix-queryserver is taken out from phoenix, thin client jar and 
queryserver jar have been renamed from 
*phoenix-thin-client.jar/phoenix-*-queryserver.jar to 
queryserver-client*SNAPSHOT.jar/queryserver-*.jar*, but phoenix_utils.py is 
still looking for the old jar files.  

Also queryserver-1.0.0-SNAPSHOT.jar probably does not contains all the 
dependency to start queryserver. I ran into a NoClassDefFoundError after I 
corrected the jar file names in phoenix_util.py. I had to modify the pom file 
to package all dependencies into the jar file in order to start queryserver 
properly. 


> python scripts not working for phoenix-queryserver
> --
>
> Key: PHOENIX-5959
> URL: https://issues.apache.org/jira/browse/PHOENIX-5959
> Project: Phoenix
>  Issue Type: Bug
>  Components: queryserver
>Affects Versions: queryserver-1.0.0
>Reporter: Jingtao Wu
>Priority: Major
>
> queryserver.py currently cannot properly start queryserver for following two 
> reasons. 
> After phoenix-queryserver is taken out from phoenix, thin client jar and 
> queryserver jar have been renamed from 
> phoenix-*thin-client.jar/phoenix*queryserver.jar to 
> queryserver-client*SNAPSHOT.jar/queryserver*.jar, but phoenix_utils.py is 
> still looking for the old jar files.  
> Also queryserver-1.0.0-SNAPSHOT.jar probably does not contains all the 
> dependency to start queryserver. I ran into a NoClassDefFoundError after I 
> corrected the jar file names in phoenix_util.py. I had to modify the pom file 
> to package all dependencies into the jar file in order to start queryserver 
> properly. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5959) python scripts not working for phoenix-queryserver

[Jingtao Wu (Jira)]

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

Jingtao Wu updated PHOENIX-5959:

Description: 
queryserver.py currently cannot properly start queryserver for following two 
reasons. 

After phoenix-queryserver is taken out from phoenix, thin client jar and 
queryserver jar have been renamed from 
*phoenix-thin-client.jar/phoenix-*-queryserver.jar to 
queryserver-client*SNAPSHOT.jar/queryserver-*.jar*, but phoenix_utils.py is 
still looking for the old jar files.  

Also queryserver-1.0.0-SNAPSHOT.jar probably does not contains all the 
dependency to start queryserver. I ran into a NoClassDefFoundError after I 
corrected the jar file names in phoenix_util.py. I had to modify the pom file 
to package all dependencies into the jar file in order to start queryserver 
properly. 

  was:
queryserver.py currently cannot properly start queryserver for following two 
reasons. 

After phoenix-queryserver is taken out from phoenix, thin client jar and 
queryserver jar have been renamed from 
phoenix-*thin-client.jar/phoenix*queryserver.jar to 
queryserver-client*SNAPSHOT.jar/queryserver*.jar, but phoenix_utils.py is still 
looking for the old jar files.  

Also queryserver-1.0.0-SNAPSHOT.jar probably does not contains all the 
dependency to start queryserver. I ran into a NoClassDefFoundError after I 
corrected the jar file names in phoenix_util.py. I had to modify the pom file 
to package all dependencies into the jar file in order to start queryserver 
properly. 


> python scripts not working for phoenix-queryserver
> --
>
> Key: PHOENIX-5959
> URL: https://issues.apache.org/jira/browse/PHOENIX-5959
> Project: Phoenix
>  Issue Type: Bug
>  Components: queryserver
>Affects Versions: queryserver-1.0.0
>Reporter: Jingtao Wu
>Priority: Major
>
> queryserver.py currently cannot properly start queryserver for following two 
> reasons. 
> After phoenix-queryserver is taken out from phoenix, thin client jar and 
> queryserver jar have been renamed from 
> *phoenix-thin-client.jar/phoenix-*-queryserver.jar to 
> queryserver-client*SNAPSHOT.jar/queryserver-*.jar*, but phoenix_utils.py is 
> still looking for the old jar files.  
> Also queryserver-1.0.0-SNAPSHOT.jar probably does not contains all the 
> dependency to start queryserver. I ran into a NoClassDefFoundError after I 
> corrected the jar file names in phoenix_util.py. I had to modify the pom file 
> to package all dependencies into the jar file in order to start queryserver 
> properly. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (PHOENIX-5961) More guide on how to start QueryServer

[Jingtao Wu (Jira)]

Jingtao Wu created PHOENIX-5961:
---

 Summary: More guide on how to start QueryServer
 Key: PHOENIX-5961
 URL: https://issues.apache.org/jira/browse/PHOENIX-5961
 Project: Phoenix
  Issue Type: Wish
  Components: queryserver
Affects Versions: queryserver-1.0.0
Reporter: Jingtao Wu


I would be good to have more guide on how to set up a working environment for 
phoenix-queryserver in README. For things like
 # How to get Phoenix client jar file
 # Which directory to put Phoenix client jar file so that queryserver.py are 
able to find it. 
 # Phoenix and Hbase versions that are supported and compatible
 # maybe attach this page for reference [https://phoenix.apache.org/server.html]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5961) More guide on how to start QueryServer

[Jingtao Wu (Jira)]

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

Jingtao Wu updated PHOENIX-5961:

Description: 
It would be good to have more guide on how to set up a working environment for 
phoenix-queryserver in README. For things like
 # How to get Phoenix client jar file
 # Which directory to put Phoenix client jar file so that queryserver.py are 
able to find it. 
 # Phoenix and Hbase versions that are supported and compatible
 # maybe attach this page for reference [https://phoenix.apache.org/server.html]

  was:
I would be good to have more guide on how to set up a working environment for 
phoenix-queryserver in README. For things like
 # How to get Phoenix client jar file
 # Which directory to put Phoenix client jar file so that queryserver.py are 
able to find it. 
 # Phoenix and Hbase versions that are supported and compatible
 # maybe attach this page for reference [https://phoenix.apache.org/server.html]


> More guide on how to start QueryServer
> --
>
> Key: PHOENIX-5961
> URL: https://issues.apache.org/jira/browse/PHOENIX-5961
> Project: Phoenix
>  Issue Type: Wish
>  Components: queryserver
>Affects Versions: queryserver-1.0.0
>Reporter: Jingtao Wu
>Priority: Minor
>
> It would be good to have more guide on how to set up a working environment 
> for phoenix-queryserver in README. For things like
>  # How to get Phoenix client jar file
>  # Which directory to put Phoenix client jar file so that queryserver.py are 
> able to find it. 
>  # Phoenix and Hbase versions that are supported and compatible
>  # maybe attach this page for reference 
> [https://phoenix.apache.org/server.html]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5960) Creating a view on a non-existent table throws the wrong exception

[Chinmay Kulkarni (Jira)]

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

Chinmay Kulkarni updated PHOENIX-5960:
--
Labels: beginner newbie phoenix-hardening quality-improvement  (was: )

> Creating a view on a non-existent table throws the wrong exception
> --
>
> Key: PHOENIX-5960
> URL: https://issues.apache.org/jira/browse/PHOENIX-5960
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.15.0
>Reporter: Chinmay Kulkarni
>Priority: Minor
>  Labels: beginner, newbie, phoenix-hardening, quality-improvement
>
> Ran across this by accident as a result of a typo in my create view statement:
> # CREATE TABLE IF NOT EXISTS *T1* (A INTEGER PRIMARY KEY, B INTEGER);
> # CREATE VIEW IF NOT EXISTS V (new_col INTEGER) AS SELECT * FROM *T2*;
> View creation fails with the following:
> {noformat}
> Error: ERROR 509 (42888): The table does not have a primary key. 
> (state=42888,code=509)
> java.sql.SQLException: ERROR 509 (42888): The table does not have a primary 
> key.
>   at 
> org.apache.phoenix.exception.SQLExceptionCode$Factory$1.newException(SQLExceptionCode.java:575)
>   at 
> org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:195)
>   at 
> org.apache.phoenix.compile.CreateTableCompiler.compile(CreateTableCompiler.java:182)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$ExecutableCreateTableStatement.compilePlan(PhoenixStatement.java:841)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$ExecutableCreateTableStatement.compilePlan(PhoenixStatement.java:830)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:407)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:397)
>   at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:396)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:384)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1886)
>   at sqlline.Commands.execute(Commands.java:814)
>   at sqlline.Commands.sql(Commands.java:754)
>   at sqlline.SqlLine.dispatch(SqlLine.java:646)
>   at sqlline.SqlLine.begin(SqlLine.java:510)
>   at sqlline.SqlLine.start(SqlLine.java:233)
>   at sqlline.SqlLine.main(SqlLine.java:175)
> {noformat}
> Ideally, this should throw a TableNotFoundException. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (PHOENIX-5960) Creating a view on a non-existent table throws the wrong exception

[Chinmay Kulkarni (Jira)]

Chinmay Kulkarni created PHOENIX-5960:
-

 Summary: Creating a view on a non-existent table throws the wrong 
exception
 Key: PHOENIX-5960
 URL: https://issues.apache.org/jira/browse/PHOENIX-5960
 Project: Phoenix
  Issue Type: Bug
Affects Versions: 4.15.0
Reporter: Chinmay Kulkarni


Ran across this by accident as a result of a typo in my create view statement:

# CREATE TABLE IF NOT EXISTS *T1* (A INTEGER PRIMARY KEY, B INTEGER);
# CREATE VIEW IF NOT EXISTS V (new_col INTEGER) AS SELECT * FROM *T2*;
View creation fails with the following:

{noformat}
Error: ERROR 509 (42888): The table does not have a primary key. 
(state=42888,code=509)
java.sql.SQLException: ERROR 509 (42888): The table does not have a primary key.
at 
org.apache.phoenix.exception.SQLExceptionCode$Factory$1.newException(SQLExceptionCode.java:575)
at 
org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:195)
at 
org.apache.phoenix.compile.CreateTableCompiler.compile(CreateTableCompiler.java:182)
at 
org.apache.phoenix.jdbc.PhoenixStatement$ExecutableCreateTableStatement.compilePlan(PhoenixStatement.java:841)
at 
org.apache.phoenix.jdbc.PhoenixStatement$ExecutableCreateTableStatement.compilePlan(PhoenixStatement.java:830)
at 
org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:407)
at 
org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:397)
at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
at 
org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:396)
at 
org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:384)
at 
org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1886)
at sqlline.Commands.execute(Commands.java:814)
at sqlline.Commands.sql(Commands.java:754)
at sqlline.SqlLine.dispatch(SqlLine.java:646)
at sqlline.SqlLine.begin(SqlLine.java:510)
at sqlline.SqlLine.start(SqlLine.java:233)
at sqlline.SqlLine.main(SqlLine.java:175)
{noformat}

Ideally, this should throw a TableNotFoundException. 




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5959) python scripts not working for phoenix-queryserver

[Jingtao Wu (Jira)]

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

Jingtao Wu updated PHOENIX-5959:

Description: 
queryserver.py currently cannot properly start queryserver for following two 
reasons. 

After phoenix-queryserver is taken out from phoenix, thin client jar and 
queryserver jar have been renamed from 
phoenix-*thin-client.jar/phoenix*queryserver.jar to 
queryserver-client*SNAPSHOT.jar/queryserver*.jar, but phoenix_utils.py is still 
looking for the old jar files.  

Also queryserver-1.0.0-SNAPSHOT.jar probably does not contains all the 
dependency to start queryserver. I ran into a NoClassDefFoundError after I 
corrected the jar file names in phoenix_util.py. I had to modify the pom file 
to package all dependencies into the jar file in order to start queryserver 
properly. 

  was:
queryserver.py currently cannot properly start queryserver for following two 
reasons. 

After phoenix-queryserver is taken out from phoenix, thin client jar and 
queryserver jar have been renamed from 
phoenix-*-thin-client.jar/phoenix-*-queryserver.jar to 
queryserver-client-*-SNAPSHOT.jar/queryserver-*.jar, but phoenix_utils.py is 
still looking for the old jar files.  

Also queryserver-1.0.0-SNAPSHOT.jar probably does not contains all the 
dependency to start queryserver. I ran into a NoClassDefFoundError after I 
corrected the jar file names in phoenix_util.py. I had to modify the pom file 
to package all dependencies into the jar file in order to start queryserver 
properly. 


> python scripts not working for phoenix-queryserver
> --
>
> Key: PHOENIX-5959
> URL: https://issues.apache.org/jira/browse/PHOENIX-5959
> Project: Phoenix
>  Issue Type: Bug
>  Components: queryserver
>Affects Versions: queryserver-1.0.0
>Reporter: Jingtao Wu
>Priority: Major
>
> queryserver.py currently cannot properly start queryserver for following two 
> reasons. 
> After phoenix-queryserver is taken out from phoenix, thin client jar and 
> queryserver jar have been renamed from 
> phoenix-*thin-client.jar/phoenix*queryserver.jar to 
> queryserver-client*SNAPSHOT.jar/queryserver*.jar, but phoenix_utils.py is 
> still looking for the old jar files.  
> Also queryserver-1.0.0-SNAPSHOT.jar probably does not contains all the 
> dependency to start queryserver. I ran into a NoClassDefFoundError after I 
> corrected the jar file names in phoenix_util.py. I had to modify the pom file 
> to package all dependencies into the jar file in order to start queryserver 
> properly. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5712) Got SYSCAT ILLEGAL_DATA exception after created tenant index on view

[Chinmay Kulkarni (Jira)]

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

Chinmay Kulkarni updated PHOENIX-5712:
--
Attachment: t.txt

> Got SYSCAT  ILLEGAL_DATA exception after created tenant index on view
> -
>
> Key: PHOENIX-5712
> URL: https://issues.apache.org/jira/browse/PHOENIX-5712
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.15.0
>Reporter: Xinyi Yan
>Priority: Major
> Fix For: 4.16.0
>
> Attachments: t.txt
>
>
> repo
> //create a multi-tenant table on global connection
> CREATE TABLE A (TENANT_ID CHAR(15) NOT NULL, ID CHAR(3) NOT NULL, NUM BIGINT 
> CONSTRAINT PK PRIMARY KEY (TENANT_ID, ID)) MULTI_TENANT = true;
> // create view and index on tenant connection
> CREATE VIEW A_VIEW AS SELECT * FROM A;
> UPSERT INTO A_VIEW (ID, NUM) VALUES ('A', 1);
> CREATE INDEX A_VIEW_INDEX ON A_VIEW (NUM DESC) INCLUDE (ID);
> // qeury data on global connection 
> SELECT * RFOM SYSTEM.CATALOG;
> {code:java}
> Error: ERROR 201 (22000): Illegal data. Expected length of at least 8 bytes, 
> but had 3 (state=22000,code=201)
> java.sql.SQLException: ERROR 201 (22000): Illegal data. Expected length of at 
> least 8 bytes, but had 3
> at 
> org.apache.phoenix.exception.SQLExceptionCode$Factory$1.newException(SQLExceptionCode.java:559)
> at 
> org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:195)
> at 
> org.apache.phoenix.schema.types.PDataType.checkForSufficientLength(PDataType.java:290)
> at 
> org.apache.phoenix.schema.types.PLong$LongCodec.decodeLong(PLong.java:256)
> at org.apache.phoenix.schema.types.PLong.toObject(PLong.java:115)
> at org.apache.phoenix.schema.types.PLong.toObject(PLong.java:31)
> at 
> org.apache.phoenix.schema.types.PDataType.toObject(PDataType.java:1011)
> at 
> org.apache.phoenix.compile.ExpressionProjector.getValue(ExpressionProjector.java:75)
> at 
> org.apache.phoenix.jdbc.PhoenixResultSet.getObject(PhoenixResultSet.java:585)
> at sqlline.Rows$Row.(Rows.java:258)
> at sqlline.BufferedRows.nextList(BufferedRows.java:111)
> at sqlline.BufferedRows.(BufferedRows.java:52)
> at sqlline.SqlLine.print(SqlLine.java:1623)
> at sqlline.Commands.execute(Commands.java:982)
> at sqlline.Commands.sql(Commands.java:906)
> at sqlline.SqlLine.dispatch(SqlLine.java:740)
> at sqlline.SqlLine.begin(SqlLine.java:557)
> at sqlline.SqlLine.start(SqlLine.java:270)
> at sqlline.SqlLine.main(SqlLine.java:201)
> {code}
> I tried to drop the view, and I was able to query the data from the SYSCATA. 
> I tested on 4.x-HBase1.3 and master branch, all branches have the same 
> behavior.
>  
> cc [~kadir] [~gjacoby] [~swaroopa]
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (PHOENIX-5959) python scripts not working for phoenix-queryserver

[Jingtao Wu (Jira)]

Jingtao Wu created PHOENIX-5959:
---

 Summary: python scripts not working for phoenix-queryserver
 Key: PHOENIX-5959
 URL: https://issues.apache.org/jira/browse/PHOENIX-5959
 Project: Phoenix
  Issue Type: Bug
  Components: queryserver
Affects Versions: queryserver-1.0.0
Reporter: Jingtao Wu


queryserver.py currently cannot properly start queryserver for following two 
reasons. 

After phoenix-queryserver is taken out from phoenix, thin client jar and 
queryserver jar have been renamed from 
phoenix-*-thin-client.jar/phoenix-*-queryserver.jar to 
queryserver-client-*-SNAPSHOT.jar/queryserver-*.jar, but phoenix_utils.py is 
still looking for the old jar files.  

Also queryserver-1.0.0-SNAPSHOT.jar probably does not contains all the 
dependency to start queryserver. I ran into a NoClassDefFoundError after I 
corrected the jar file names in phoenix_util.py. I had to modify the pom file 
to package all dependencies into the jar file in order to start queryserver 
properly. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] Public Python PhoenixDB releases

[Josh Elser]

ASF releases do not have to be on the order of years. As long as we have 
three people to vote, we can do releases as often as we'd like. The 
lower-bound on release cadence is probably on the order of "weeks" (as 
opposed to days) but that's primarily limited by bandwidth of our 
volunteers :)


Anyways, if that's the major worry, let's just push to doing proper 
votes. We should not have the problem in having people turn out to vote.


I'll put L review to the top of my list to do (my) tomorrow morning. 
Sorry I haven't gotten to it yet.


On 6/15/20 1:42 PM, Istvan Toth wrote:

TestPyPi certainly seems useful to practice the release process, and avoid
mistakes with it.

However, I don't think that it is a substitute for a .devN release, which
(in my mind) is meant to give the users something to use until we get all
our ducks in a row to do a proper 1.0 release. The primary user in this
case would be Hue, which needs the new features, and is currently mirroring
our dev sources into their own repo. (TBH, that's their normal modus
operandi anyway, but for their Python 3 version, they'd like to switch to
PyPI  modules)

To use a dev package, the users have to explicitly specify the exact
development version, (or go all-out, and use development versions of all
packages), so there is no chance of them accidentally upgrading from a
stable release. Making them specify another repo as well to install a dev
release sounds like too much to me.

If on the other hand we plan on releasing  the current state of PhoenixDB
as 1.0 soon (like in month), and then do frequent-ish releases as new
features/fixes are (hopefully) added, then we can skip the dev releases
altogether. The Phoenix norm so far is more like yearly releases (if we are
lucky).

regards
István

On Mon, Jun 15, 2020 at 7:08 PM Josh Elser  wrote:


Did a little searching..

* Found a 2011 blog post from sqlalchemy which said (as a project) they
would not post devN releases to pypi
* There's a TestPyPi [1] instead which seems to be for staging work.

Could we play with staging there? And then push to pypi (real) after we
do a normal vote?

I think we can keep our python release super-low friction :)

[1] https://packaging.python.org/guides/using-testpypi/

On 6/15/20 1:02 PM, Josh Elser wrote:

Hey Istvan,

Great of you to drive this work!

I do have one concern about pushing the dev releases to PyPi (I'm
assuming that's what you mean). I understand that in the Python world a
"dev" release indicates that this isn't an "official" release [1].

At the ASF, you're correct that we, developers, are empowered to make
"builds" of our product(s) for the sake of our development. There is a
clear line when that "build" is published in a location to which a user
may find it and begin to use it. There has been at least one example in
recent memory of a project which made "developer only releases" without
proper voting, but published them in a high-visibility location and
(inadvertently or intentionally) circumvented the ASF release

requirements.


My biggest concern is: would a user who ran a `pip install phoenixdb`
after we make a devN release get the last-stable release (0.7) or the
new devN release? If they would get the dev release, does PyPi give us
any flexibility to prevent this from happening? I believe that we should
consider publishing to the "official" location should be treated as a
release if it means that a user could begin to use it with "low

friction".


- Josh


[1] https://www.python.org/dev/peps/pep-0440/#id24

On 6/12/20 7:11 AM, Istvan Toth wrote:

Hi!

Even though we have adopted the PhoenixDB driver in 2018, there hasn't
been
much activity on it, and the version available on PyPI is still the
old 0.7
release by Lukas.

Recently I have worked on it quite a bit, adding fixes and new features,
and adopting the partial SQLAlchemy driver from pyPhoenix, thus enabling
Hue support.

I plan to start releasing the driver publicly on PyPI. Lukas has kindly
shared control of the PyPI phoenixdb project with us, so we are good
to go.

The short-term plan is to release 1.0.0.dev0 and later 1.0.0.devN
releases
from the current HEAD of phoenix-queryserver. As these will be dev
releases, I am not planning to follow a formal release process for

these.


When and how to release 1.0.0 final, and the versioning scheme/process

to

use  after that are still not finalized.

Please join the discussion here, or in
https://issues.apache.org/jira/browse/PHOENIX-5939 if you have any
questions or suggestions!

regards
Istvan

[jira] [Updated] (PHOENIX-5712) Got SYSCAT ILLEGAL_DATA exception after created tenant index on view

[Chinmay Kulkarni (Jira)]

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

Chinmay Kulkarni updated PHOENIX-5712:
--
Fix Version/s: 4.16.0

> Got SYSCAT  ILLEGAL_DATA exception after created tenant index on view
> -
>
> Key: PHOENIX-5712
> URL: https://issues.apache.org/jira/browse/PHOENIX-5712
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.15.0
>Reporter: Xinyi Yan
>Priority: Major
> Fix For: 4.16.0
>
>
> repo
> //create a multi-tenant table on global connection
> CREATE TABLE A (TENANT_ID CHAR(15) NOT NULL, ID CHAR(3) NOT NULL, NUM BIGINT 
> CONSTRAINT PK PRIMARY KEY (TENANT_ID, ID)) MULTI_TENANT = true;
> // create view and index on tenant connection
> CREATE VIEW A_VIEW AS SELECT * FROM A;
> UPSERT INTO A_VIEW (ID, NUM) VALUES ('A', 1);
> CREATE INDEX A_VIEW_INDEX ON A_VIEW (NUM DESC) INCLUDE (ID);
> // qeury data on global connection 
> SELECT * RFOM SYSTEM.CATALOG;
> {code:java}
> Error: ERROR 201 (22000): Illegal data. Expected length of at least 8 bytes, 
> but had 3 (state=22000,code=201)
> java.sql.SQLException: ERROR 201 (22000): Illegal data. Expected length of at 
> least 8 bytes, but had 3
> at 
> org.apache.phoenix.exception.SQLExceptionCode$Factory$1.newException(SQLExceptionCode.java:559)
> at 
> org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:195)
> at 
> org.apache.phoenix.schema.types.PDataType.checkForSufficientLength(PDataType.java:290)
> at 
> org.apache.phoenix.schema.types.PLong$LongCodec.decodeLong(PLong.java:256)
> at org.apache.phoenix.schema.types.PLong.toObject(PLong.java:115)
> at org.apache.phoenix.schema.types.PLong.toObject(PLong.java:31)
> at 
> org.apache.phoenix.schema.types.PDataType.toObject(PDataType.java:1011)
> at 
> org.apache.phoenix.compile.ExpressionProjector.getValue(ExpressionProjector.java:75)
> at 
> org.apache.phoenix.jdbc.PhoenixResultSet.getObject(PhoenixResultSet.java:585)
> at sqlline.Rows$Row.(Rows.java:258)
> at sqlline.BufferedRows.nextList(BufferedRows.java:111)
> at sqlline.BufferedRows.(BufferedRows.java:52)
> at sqlline.SqlLine.print(SqlLine.java:1623)
> at sqlline.Commands.execute(Commands.java:982)
> at sqlline.Commands.sql(Commands.java:906)
> at sqlline.SqlLine.dispatch(SqlLine.java:740)
> at sqlline.SqlLine.begin(SqlLine.java:557)
> at sqlline.SqlLine.start(SqlLine.java:270)
> at sqlline.SqlLine.main(SqlLine.java:201)
> {code}
> I tried to drop the view, and I was able to query the data from the SYSCATA. 
> I tested on 4.x-HBase1.3 and master branch, all branches have the same 
> behavior.
>  
> cc [~kadir] [~gjacoby] [~swaroopa]
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5712) Got SYSCAT ILLEGAL_DATA exception after created tenant index on view

[Chinmay Kulkarni (Jira)]

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

Chinmay Kulkarni updated PHOENIX-5712:
--
Affects Version/s: 4.15.0

> Got SYSCAT  ILLEGAL_DATA exception after created tenant index on view
> -
>
> Key: PHOENIX-5712
> URL: https://issues.apache.org/jira/browse/PHOENIX-5712
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.15.0
>Reporter: Xinyi Yan
>Priority: Major
>
> repo
> //create a multi-tenant table on global connection
> CREATE TABLE A (TENANT_ID CHAR(15) NOT NULL, ID CHAR(3) NOT NULL, NUM BIGINT 
> CONSTRAINT PK PRIMARY KEY (TENANT_ID, ID)) MULTI_TENANT = true;
> // create view and index on tenant connection
> CREATE VIEW A_VIEW AS SELECT * FROM A;
> UPSERT INTO A_VIEW (ID, NUM) VALUES ('A', 1);
> CREATE INDEX A_VIEW_INDEX ON A_VIEW (NUM DESC) INCLUDE (ID);
> // qeury data on global connection 
> SELECT * RFOM SYSTEM.CATALOG;
> {code:java}
> Error: ERROR 201 (22000): Illegal data. Expected length of at least 8 bytes, 
> but had 3 (state=22000,code=201)
> java.sql.SQLException: ERROR 201 (22000): Illegal data. Expected length of at 
> least 8 bytes, but had 3
> at 
> org.apache.phoenix.exception.SQLExceptionCode$Factory$1.newException(SQLExceptionCode.java:559)
> at 
> org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:195)
> at 
> org.apache.phoenix.schema.types.PDataType.checkForSufficientLength(PDataType.java:290)
> at 
> org.apache.phoenix.schema.types.PLong$LongCodec.decodeLong(PLong.java:256)
> at org.apache.phoenix.schema.types.PLong.toObject(PLong.java:115)
> at org.apache.phoenix.schema.types.PLong.toObject(PLong.java:31)
> at 
> org.apache.phoenix.schema.types.PDataType.toObject(PDataType.java:1011)
> at 
> org.apache.phoenix.compile.ExpressionProjector.getValue(ExpressionProjector.java:75)
> at 
> org.apache.phoenix.jdbc.PhoenixResultSet.getObject(PhoenixResultSet.java:585)
> at sqlline.Rows$Row.(Rows.java:258)
> at sqlline.BufferedRows.nextList(BufferedRows.java:111)
> at sqlline.BufferedRows.(BufferedRows.java:52)
> at sqlline.SqlLine.print(SqlLine.java:1623)
> at sqlline.Commands.execute(Commands.java:982)
> at sqlline.Commands.sql(Commands.java:906)
> at sqlline.SqlLine.dispatch(SqlLine.java:740)
> at sqlline.SqlLine.begin(SqlLine.java:557)
> at sqlline.SqlLine.start(SqlLine.java:270)
> at sqlline.SqlLine.main(SqlLine.java:201)
> {code}
> I tried to drop the view, and I was able to query the data from the SYSCATA. 
> I tested on 4.x-HBase1.3 and master branch, all branches have the same 
> behavior.
>  
> cc [~kadir] [~gjacoby] [~swaroopa]
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5958) Diverged view created from an older client still sees dropped column data

[Chinmay Kulkarni (Jira)]

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

Chinmay Kulkarni updated PHOENIX-5958:
--
Priority: Major  (was: Blocker)

> Diverged view created from an older client still sees dropped column data
> -
>
> Key: PHOENIX-5958
> URL: https://issues.apache.org/jira/browse/PHOENIX-5958
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.15.0
>Reporter: Chinmay Kulkarni
>Priority: Major
> Fix For: 4.16.0
>
>
> By "diverged view" I mean creating a view and then dropping one of the 
> inherited columns from the view. Steps to reproduce:
> Start a 4.x server and connect with a pre-4.15 (I tried a 4.14.3) client
>  # CREATE TABLE IF NOT EXISTS S.T (A INTEGER PRIMARY KEY, B INTEGER);
>  # CREATE VIEW IF NOT EXISTS S.V (new_col INTEGER) AS SELECT * FROM S.T;
>  # UPSERT INTO S.T VALUES(1,2);
>  # ALTER VIEW S.V DROP COLUMN B;
>  # SELECT * FROM S.T; gives:
> |A|B|
> |1|2|
>  # SELECT * FROM S.V; gives:
> |B|A|NEW_COL|
> |2|1|null|
> Though the column 'B' has been dropped from the view. This does not happen 
> for a 4.x client. 
> The problem is mostly due to changes introduced by 
> [PHOENIX-4893|https://issues.apache.org/jira/browse/PHOENIX-4893].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (PHOENIX-5958) Diverged view created from an older client still sees dropped column data

[Chinmay Kulkarni (Jira)]

Chinmay Kulkarni created PHOENIX-5958:
-

 Summary: Diverged view created from an older client still sees 
dropped column data
 Key: PHOENIX-5958
 URL: https://issues.apache.org/jira/browse/PHOENIX-5958
 Project: Phoenix
  Issue Type: Bug
Affects Versions: 4.15.0
Reporter: Chinmay Kulkarni
 Fix For: 4.16.0


By "diverged view" I mean creating a view and then dropping one of the 
inherited columns from the view. Steps to reproduce:

Start a 4.x server and connect with a pre-4.15 (I tried a 4.14.3) client
 # CREATE TABLE IF NOT EXISTS S.T (A INTEGER PRIMARY KEY, B INTEGER);
 # CREATE VIEW IF NOT EXISTS S.V (new_col INTEGER) AS SELECT * FROM S.T;
 # UPSERT INTO S.T VALUES(1,2);
 # ALTER VIEW S.V DROP COLUMN B;
 # SELECT * FROM S.T; gives:

|A|B|
|1|2|

 # SELECT * FROM S.V; gives:

|B|A|NEW_COL|
|2|1|null|

Though the column 'B' has been dropped from the view. This does not happen for 
a 4.x client. 
The problem is mostly due to changes introduced by 
[PHOENIX-4893|https://issues.apache.org/jira/browse/PHOENIX-4893].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (PHOENIX-5957) Index rebuild should remove old index rows with higher timestamp

[Kadir OZDEMIR (Jira)]

Kadir OZDEMIR created PHOENIX-5957:
--

 Summary: Index rebuild should remove old index rows with higher 
timestamp
 Key: PHOENIX-5957
 URL: https://issues.apache.org/jira/browse/PHOENIX-5957
 Project: Phoenix
  Issue Type: Improvement
Affects Versions: 4.14.3, 5.0.0
Reporter: Kadir OZDEMIR


During the upgrade of index tables from the old design to the new design, we 
rebuild the index table rows online. Rebuilding index table rows using the new 
design is supposed to be overwriting the old index rows. Due to a bug in the 
old implementation of the index tool (fixed by PHOENIX-5018), the old index row 
likely have higher timestamps than their data table rows. Since the current 
implementation of the index tool correctly sets the index row timestamps using 
the data table row timestamps, newly rebuilt index rows become older versions 
of the old index rows. So, essentially they do not overwrite old index rows. 
This does not cause correctness issue as the old rows are repaired by the read 
repair feature of the new design but increases the number of read repair 
operations, and thus, causes performance issues.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5924) RVC Offset does not handle variable length fields exclusive scan boundary correctly

[Daniel Wong (Jira)]

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

Daniel Wong updated PHOENIX-5924:
-
Attachment: (was: PHOENIX-5924-4.x.patch)

> RVC Offset does not handle variable length fields exclusive scan boundary 
> correctly
> ---
>
> Key: PHOENIX-5924
> URL: https://issues.apache.org/jira/browse/PHOENIX-5924
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 5.0.0, 4.15.0, 4.14.3
>Reporter: Daniel Wong
>Assignee: Daniel Wong
>Priority: Major
> Fix For: 5.1.0, 4.16.0
>
> Attachments: PHOENIX-5924-4.x.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The way exclusive boundary was handled by incrementing the key for variable 
> length fields is incorrect in the scan boundary.
>  
> In the following case we incrementing incorrectly from 0x490049 -> 0x490050 
> ('1','1' -> '1','2')
> We should increment from 0x490049 -> 0x49004900 ('1','1' -> '1','1'\x00) 
> @Test
> public void testScenario() throws Exception \{
> String TEST_DDL = "CREATE TABLE IF NOT EXISTS TEST_SCHEMA (\n"
> + "ORGANIZATION_ID VARCHAR(15), \n" + "TEST_ID 
> VARCHAR(15), \n"
> + "CREATED_DATE DATE, \n" + "LAST_UPDATE DATE\n"
> + "CONSTRAINT TEST_SCHEMA_PK PRIMARY KEY (ORGANIZATION_ID, 
> TEST_ID) \n" + ")";
> try (Statement statement = conn.createStatement()) {
> statement.execute(TEST_DDL);
> }
> //setup
> List upserts = new ArrayList<>();
> upserts.add("UPSERT INTO TEST_SCHEMA(ORGANIZATION_ID,TEST_ID) VALUES 
> ('1','1')");
> upserts.add("UPSERT INTO TEST_SCHEMA(ORGANIZATION_ID,TEST_ID) VALUES 
> ('1','10')");
> upserts.add("UPSERT INTO TEST_SCHEMA(ORGANIZATION_ID,TEST_ID) VALUES 
> ('2','2')");
> for(String sql : upserts) \{
> try (Statement statement = conn.createStatement()) {
> statement.execute(sql);
> }
> }
> conn.commit();
> String query1 = "SELECT * FROM TEST_SCHEMA";
> String query2 = "SELECT * FROM TEST_SCHEMA OFFSET 
> (ORGANIZATION_ID,TEST_ID) = ('1','1')";
> try (Statement statement = conn.createStatement() ; ResultSet rs1 = 
> statement.executeQuery(query1) ) \{
> TestUtil.printResultSet(rs1);
> }
> try (Statement statement = conn.createStatement() ; ResultSet rs2 = 
> statement.executeQuery(query2) ) \{
> TestUtil.printResultSet(rs2);
> }
> }
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5924) RVC Offset does not handle variable length fields exclusive scan boundary correctly

[Daniel Wong (Jira)]

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

Daniel Wong updated PHOENIX-5924:
-
Attachment: PHOENIX-5924-4.x.patch

> RVC Offset does not handle variable length fields exclusive scan boundary 
> correctly
> ---
>
> Key: PHOENIX-5924
> URL: https://issues.apache.org/jira/browse/PHOENIX-5924
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 5.0.0, 4.15.0, 4.14.3
>Reporter: Daniel Wong
>Assignee: Daniel Wong
>Priority: Major
> Fix For: 5.1.0, 4.16.0
>
> Attachments: PHOENIX-5924-4.x.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The way exclusive boundary was handled by incrementing the key for variable 
> length fields is incorrect in the scan boundary.
>  
> In the following case we incrementing incorrectly from 0x490049 -> 0x490050 
> ('1','1' -> '1','2')
> We should increment from 0x490049 -> 0x49004900 ('1','1' -> '1','1'\x00) 
> @Test
> public void testScenario() throws Exception \{
> String TEST_DDL = "CREATE TABLE IF NOT EXISTS TEST_SCHEMA (\n"
> + "ORGANIZATION_ID VARCHAR(15), \n" + "TEST_ID 
> VARCHAR(15), \n"
> + "CREATED_DATE DATE, \n" + "LAST_UPDATE DATE\n"
> + "CONSTRAINT TEST_SCHEMA_PK PRIMARY KEY (ORGANIZATION_ID, 
> TEST_ID) \n" + ")";
> try (Statement statement = conn.createStatement()) {
> statement.execute(TEST_DDL);
> }
> //setup
> List upserts = new ArrayList<>();
> upserts.add("UPSERT INTO TEST_SCHEMA(ORGANIZATION_ID,TEST_ID) VALUES 
> ('1','1')");
> upserts.add("UPSERT INTO TEST_SCHEMA(ORGANIZATION_ID,TEST_ID) VALUES 
> ('1','10')");
> upserts.add("UPSERT INTO TEST_SCHEMA(ORGANIZATION_ID,TEST_ID) VALUES 
> ('2','2')");
> for(String sql : upserts) \{
> try (Statement statement = conn.createStatement()) {
> statement.execute(sql);
> }
> }
> conn.commit();
> String query1 = "SELECT * FROM TEST_SCHEMA";
> String query2 = "SELECT * FROM TEST_SCHEMA OFFSET 
> (ORGANIZATION_ID,TEST_ID) = ('1','1')";
> try (Statement statement = conn.createStatement() ; ResultSet rs1 = 
> statement.executeQuery(query1) ) \{
> TestUtil.printResultSet(rs1);
> }
> try (Statement statement = conn.createStatement() ; ResultSet rs2 = 
> statement.executeQuery(query2) ) \{
> TestUtil.printResultSet(rs2);
> }
> }
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Master branch does not compile

[swaroopa kadam]

Thank you for the response, Andrew and Geoffrey. Below is the error message
I see:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-dependency-plugin:3.1.1:analyze-only
(enforce-dependencies) on project phoenix-core: Dependency problems found
-> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the
command
[ERROR]   mvn  -rf :phoenix-core


On Mon, Jun 15, 2020 at 10:45 AM Geoffrey Jacoby
 wrote:

> git checkout master, then git pull, then mvn clean package -DskipTests
> passes for me, and I double-checked with git status that I don't have
> anything "extra" in my local environment.
>
> Geoffrey
>
> On Mon, Jun 15, 2020 at 10:29 AM Andrew Purtell 
> wrote:
>
> > Apache mailing list software stripps embedded images. Please post text.
> >
> >
> > On Mon, Jun 15, 2020 at 10:24 AM swaroopa kadam <
> > swaroopa.kada...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > I am trying to compile the master branch of phoenix and I get the
> > > following error message.
> > > What has changed recently? Do I need to make additional changes?
> > >
> > > Thanks.
> > >
> > > [image: Screen Shot 2020-06-12 at 6.02.25 PM.png]
> > >
> > > --
> > >
> > >
> > > Swaroopa Kadam
> > > [image: https://]about.me/swaroopa_kadam
> > > <
> >
> https://about.me/swaroopa_kadam?promo=email_sig_source=product_medium=email_sig_campaign=gmail_api
> > >
> > >
> >
> >
> > --
> > Best regards,
> > Andrew
> >
> > Words like orphans lost among the crosstalk, meaning torn from truth's
> > decrepit hands
> >- A23, Crosstalk
> >
>


-- 


Swaroopa Kadam
[image: https://]about.me/swaroopa_kadam

Re: [DISCUSS] Public Python PhoenixDB releases

[Josh Elser]

One more thing :)

Apache Beam appears to have an excellent release guide which includes 
their process which involves PyPi -- 
https://beam.apache.org/contribute/release-guide/


Maybe we can copy them?

On 6/15/20 1:08 PM, Josh Elser wrote:

Did a little searching..

* Found a 2011 blog post from sqlalchemy which said (as a project) they 
would not post devN releases to pypi

* There's a TestPyPi [1] instead which seems to be for staging work.

Could we play with staging there? And then push to pypi (real) after we 
do a normal vote?


I think we can keep our python release super-low friction :)

[1] https://packaging.python.org/guides/using-testpypi/

On 6/15/20 1:02 PM, Josh Elser wrote:

Hey Istvan,

Great of you to drive this work!

I do have one concern about pushing the dev releases to PyPi (I'm 
assuming that's what you mean). I understand that in the Python world 
a "dev" release indicates that this isn't an "official" release [1].


At the ASF, you're correct that we, developers, are empowered to make 
"builds" of our product(s) for the sake of our development. There is a 
clear line when that "build" is published in a location to which a 
user may find it and begin to use it. There has been at least one 
example in recent memory of a project which made "developer only 
releases" without proper voting, but published them in a 
high-visibility location and (inadvertently or intentionally) 
circumvented the ASF release requirements.


My biggest concern is: would a user who ran a `pip install phoenixdb` 
after we make a devN release get the last-stable release (0.7) or the 
new devN release? If they would get the dev release, does PyPi give us 
any flexibility to prevent this from happening? I believe that we 
should consider publishing to the "official" location should be 
treated as a release if it means that a user could begin to use it 
with "low friction".


- Josh


[1] https://www.python.org/dev/peps/pep-0440/#id24

On 6/12/20 7:11 AM, Istvan Toth wrote:

Hi!

Even though we have adopted the PhoenixDB driver in 2018, there 
hasn't been
much activity on it, and the version available on PyPI is still the 
old 0.7

release by Lukas.

Recently I have worked on it quite a bit, adding fixes and new features,
and adopting the partial SQLAlchemy driver from pyPhoenix, thus enabling
Hue support.

I plan to start releasing the driver publicly on PyPI. Lukas has kindly
shared control of the PyPI phoenixdb project with us, so we are good 
to go.


The short-term plan is to release 1.0.0.dev0 and later 1.0.0.devN 
releases

from the current HEAD of phoenix-queryserver. As these will be dev
releases, I am not planning to follow a formal release process for 
these.


When and how to release 1.0.0 final, and the versioning 
scheme/process to

use  after that are still not finalized.

Please join the discussion here, or in
https://issues.apache.org/jira/browse/PHOENIX-5939 if you have any
questions or suggestions!

regards
Istvan

Re: Master branch does not compile

[Geoffrey Jacoby]

git checkout master, then git pull, then mvn clean package -DskipTests
passes for me, and I double-checked with git status that I don't have
anything "extra" in my local environment.

Geoffrey

On Mon, Jun 15, 2020 at 10:29 AM Andrew Purtell  wrote:

> Apache mailing list software stripps embedded images. Please post text.
>
>
> On Mon, Jun 15, 2020 at 10:24 AM swaroopa kadam <
> swaroopa.kada...@gmail.com>
> wrote:
>
> > Hi,
> >
> > I am trying to compile the master branch of phoenix and I get the
> > following error message.
> > What has changed recently? Do I need to make additional changes?
> >
> > Thanks.
> >
> > [image: Screen Shot 2020-06-12 at 6.02.25 PM.png]
> >
> > --
> >
> >
> > Swaroopa Kadam
> > [image: https://]about.me/swaroopa_kadam
> > <
> https://about.me/swaroopa_kadam?promo=email_sig_source=product_medium=email_sig_campaign=gmail_api
> >
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: [DISCUSS] Public Python PhoenixDB releases

[Istvan Toth]

TestPyPi certainly seems useful to practice the release process, and avoid
mistakes with it.

However, I don't think that it is a substitute for a .devN release, which
(in my mind) is meant to give the users something to use until we get all
our ducks in a row to do a proper 1.0 release. The primary user in this
case would be Hue, which needs the new features, and is currently mirroring
our dev sources into their own repo. (TBH, that's their normal modus
operandi anyway, but for their Python 3 version, they'd like to switch to
PyPI  modules)

To use a dev package, the users have to explicitly specify the exact
development version, (or go all-out, and use development versions of all
packages), so there is no chance of them accidentally upgrading from a
stable release. Making them specify another repo as well to install a dev
release sounds like too much to me.

If on the other hand we plan on releasing  the current state of PhoenixDB
as 1.0 soon (like in month), and then do frequent-ish releases as new
features/fixes are (hopefully) added, then we can skip the dev releases
altogether. The Phoenix norm so far is more like yearly releases (if we are
lucky).

regards
István

On Mon, Jun 15, 2020 at 7:08 PM Josh Elser  wrote:

> Did a little searching..
>
> * Found a 2011 blog post from sqlalchemy which said (as a project) they
> would not post devN releases to pypi
> * There's a TestPyPi [1] instead which seems to be for staging work.
>
> Could we play with staging there? And then push to pypi (real) after we
> do a normal vote?
>
> I think we can keep our python release super-low friction :)
>
> [1] https://packaging.python.org/guides/using-testpypi/
>
> On 6/15/20 1:02 PM, Josh Elser wrote:
> > Hey Istvan,
> >
> > Great of you to drive this work!
> >
> > I do have one concern about pushing the dev releases to PyPi (I'm
> > assuming that's what you mean). I understand that in the Python world a
> > "dev" release indicates that this isn't an "official" release [1].
> >
> > At the ASF, you're correct that we, developers, are empowered to make
> > "builds" of our product(s) for the sake of our development. There is a
> > clear line when that "build" is published in a location to which a user
> > may find it and begin to use it. There has been at least one example in
> > recent memory of a project which made "developer only releases" without
> > proper voting, but published them in a high-visibility location and
> > (inadvertently or intentionally) circumvented the ASF release
> requirements.
> >
> > My biggest concern is: would a user who ran a `pip install phoenixdb`
> > after we make a devN release get the last-stable release (0.7) or the
> > new devN release? If they would get the dev release, does PyPi give us
> > any flexibility to prevent this from happening? I believe that we should
> > consider publishing to the "official" location should be treated as a
> > release if it means that a user could begin to use it with "low
> friction".
> >
> > - Josh
> >
> >
> > [1] https://www.python.org/dev/peps/pep-0440/#id24
> >
> > On 6/12/20 7:11 AM, Istvan Toth wrote:
> >> Hi!
> >>
> >> Even though we have adopted the PhoenixDB driver in 2018, there hasn't
> >> been
> >> much activity on it, and the version available on PyPI is still the
> >> old 0.7
> >> release by Lukas.
> >>
> >> Recently I have worked on it quite a bit, adding fixes and new features,
> >> and adopting the partial SQLAlchemy driver from pyPhoenix, thus enabling
> >> Hue support.
> >>
> >> I plan to start releasing the driver publicly on PyPI. Lukas has kindly
> >> shared control of the PyPI phoenixdb project with us, so we are good
> >> to go.
> >>
> >> The short-term plan is to release 1.0.0.dev0 and later 1.0.0.devN
> >> releases
> >> from the current HEAD of phoenix-queryserver. As these will be dev
> >> releases, I am not planning to follow a formal release process for
> these.
> >>
> >> When and how to release 1.0.0 final, and the versioning scheme/process
> to
> >> use  after that are still not finalized.
> >>
> >> Please join the discussion here, or in
> >> https://issues.apache.org/jira/browse/PHOENIX-5939 if you have any
> >> questions or suggestions!
> >>
> >> regards
> >> Istvan
> >>
>


-- 
*István Tóth* | Staff Software Engineer
st...@cloudera.com 
[image: Cloudera] 
[image: Cloudera on Twitter]  [image:
Cloudera on Facebook]  [image: Cloudera
on LinkedIn] 

--

Re: No builds on Phoenix-Master jenkins since Feb 19th?

[Andrew Purtell]

So it's time to enforce an automatic revert if build fails policy?
Ideally, no commit before a precommit passes.
If that fails, if someone discovers failing tests and can git bisect to the
cause, automatic revert of the offending commit.

YDYT?


On Sun, Jun 14, 2020 at 10:20 PM Istvan Toth 
wrote:

> Unfortunately you are not missing anything, Lars :(
>
> What's worse, the tests are not only failing, they even hang since Jun 2.
> Master is in a similar state.
>
> regards
> Istvan
>
> On Sun, Jun 14, 2020 at 12:03 AM la...@apache.org 
> wrote:
>
> > Thanks Istvan.
> >
> > Just checked the builds. Looks like the 4.x builds have not passed a
> > single time since May 20th.
> >
> > I hope I am missing something... Otherwise this would be pretty
> > frustrating. :)
> > (Since pleading doesn't appear to help, maybe we should automatically
> > block all commits until all tests pass...?)
> >
> > -- Lars
> >
> >
> > On Tuesday, April 21, 2020, 5:33:52 AM PDT, Istvan Toth <
> st...@apache.org>
> > wrote:
> >
> >
> >
> >
> >
> > I've deleted all but the four Phoenix jobs listed in the JIRA.
> >
> >
>
> --
> *István Tóth* | Staff Software Engineer
> st...@cloudera.com 
> [image: Cloudera] 
> [image: Cloudera on Twitter]  [image:
> Cloudera on Facebook]  [image: Cloudera
> on LinkedIn] 
> 
> --
>


-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: Master branch does not compile

[Andrew Purtell]

Apache mailing list software stripps embedded images. Please post text.


On Mon, Jun 15, 2020 at 10:24 AM swaroopa kadam 
wrote:

> Hi,
>
> I am trying to compile the master branch of phoenix and I get the
> following error message.
> What has changed recently? Do I need to make additional changes?
>
> Thanks.
>
> [image: Screen Shot 2020-06-12 at 6.02.25 PM.png]
>
> --
>
>
> Swaroopa Kadam
> [image: https://]about.me/swaroopa_kadam
> 
>


-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Master branch does not compile

[swaroopa kadam]

Hi,

I am trying to compile the master branch of phoenix and I get the
following error message.
What has changed recently? Do I need to make additional changes?

Thanks.

[image: Screen Shot 2020-06-12 at 6.02.25 PM.png]

-- 


Swaroopa Kadam
[image: https://]about.me/swaroopa_kadam

Re: [DISCUSS] Public Python PhoenixDB releases

[Josh Elser]

Did a little searching..

* Found a 2011 blog post from sqlalchemy which said (as a project) they 
would not post devN releases to pypi

* There's a TestPyPi [1] instead which seems to be for staging work.

Could we play with staging there? And then push to pypi (real) after we 
do a normal vote?


I think we can keep our python release super-low friction :)

[1] https://packaging.python.org/guides/using-testpypi/

On 6/15/20 1:02 PM, Josh Elser wrote:

Hey Istvan,

Great of you to drive this work!

I do have one concern about pushing the dev releases to PyPi (I'm 
assuming that's what you mean). I understand that in the Python world a 
"dev" release indicates that this isn't an "official" release [1].


At the ASF, you're correct that we, developers, are empowered to make 
"builds" of our product(s) for the sake of our development. There is a 
clear line when that "build" is published in a location to which a user 
may find it and begin to use it. There has been at least one example in 
recent memory of a project which made "developer only releases" without 
proper voting, but published them in a high-visibility location and 
(inadvertently or intentionally) circumvented the ASF release requirements.


My biggest concern is: would a user who ran a `pip install phoenixdb` 
after we make a devN release get the last-stable release (0.7) or the 
new devN release? If they would get the dev release, does PyPi give us 
any flexibility to prevent this from happening? I believe that we should 
consider publishing to the "official" location should be treated as a 
release if it means that a user could begin to use it with "low friction".


- Josh


[1] https://www.python.org/dev/peps/pep-0440/#id24

On 6/12/20 7:11 AM, Istvan Toth wrote:

Hi!

Even though we have adopted the PhoenixDB driver in 2018, there hasn't 
been
much activity on it, and the version available on PyPI is still the 
old 0.7

release by Lukas.

Recently I have worked on it quite a bit, adding fixes and new features,
and adopting the partial SQLAlchemy driver from pyPhoenix, thus enabling
Hue support.

I plan to start releasing the driver publicly on PyPI. Lukas has kindly
shared control of the PyPI phoenixdb project with us, so we are good 
to go.


The short-term plan is to release 1.0.0.dev0 and later 1.0.0.devN 
releases

from the current HEAD of phoenix-queryserver. As these will be dev
releases, I am not planning to follow a formal release process for these.

When and how to release 1.0.0 final, and the versioning scheme/process to
use  after that are still not finalized.

Please join the discussion here, or in
https://issues.apache.org/jira/browse/PHOENIX-5939 if you have any
questions or suggestions!

regards
Istvan

Re: [DISCUSS] Public Python PhoenixDB releases

[Josh Elser]

Hey Istvan,

Great of you to drive this work!

I do have one concern about pushing the dev releases to PyPi (I'm 
assuming that's what you mean). I understand that in the Python world a 
"dev" release indicates that this isn't an "official" release [1].


At the ASF, you're correct that we, developers, are empowered to make 
"builds" of our product(s) for the sake of our development. There is a 
clear line when that "build" is published in a location to which a user 
may find it and begin to use it. There has been at least one example in 
recent memory of a project which made "developer only releases" without 
proper voting, but published them in a high-visibility location and 
(inadvertently or intentionally) circumvented the ASF release requirements.


My biggest concern is: would a user who ran a `pip install phoenixdb` 
after we make a devN release get the last-stable release (0.7) or the 
new devN release? If they would get the dev release, does PyPi give us 
any flexibility to prevent this from happening? I believe that we should 
consider publishing to the "official" location should be treated as a 
release if it means that a user could begin to use it with "low friction".


- Josh


[1] https://www.python.org/dev/peps/pep-0440/#id24

On 6/12/20 7:11 AM, Istvan Toth wrote:

Hi!

Even though we have adopted the PhoenixDB driver in 2018, there hasn't been
much activity on it, and the version available on PyPI is still the old 0.7
release by Lukas.

Recently I have worked on it quite a bit, adding fixes and new features,
and adopting the partial SQLAlchemy driver from pyPhoenix, thus enabling
Hue support.

I plan to start releasing the driver publicly on PyPI. Lukas has kindly
shared control of the PyPI phoenixdb project with us, so we are good to go.

The short-term plan is to release 1.0.0.dev0 and later 1.0.0.devN releases
from the current HEAD of phoenix-queryserver. As these will be dev
releases, I am not planning to follow a formal release process for these.

When and how to release 1.0.0 final, and the versioning scheme/process to
use  after that are still not finalized.

Please join the discussion here, or in
https://issues.apache.org/jira/browse/PHOENIX-5939 if you have any
questions or suggestions!

regards
Istvan