[jira] [Commented] (PHOENIX-2628) Ensure split when iterating through results handled correctly

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2628:
-

Github user JamesRTaylor commented on the pull request:

https://github.com/apache/phoenix/pull/156#issuecomment-207677080
  
+1. Looks great, @chrajeshbabu. Thanks for the excellent work.


> Ensure split when iterating through results handled correctly
> -
>
> Key: PHOENIX-2628
> URL: https://issues.apache.org/jira/browse/PHOENIX-2628
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: Rajeshbabu Chintaguntla
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2628-wip.patch, PHOENIX-2628.patch, 
> PHOENIX-2628_v7.patch, PHOENIX-2628_v8.patch
>
>
> We should start with a test case to ensure this works correctly, both for 
> scans and aggregates.



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

[GitHub] phoenix pull request: PHOENIX-2628 Ensure split when iterating thr...

[JamesRTaylor]

Github user JamesRTaylor commented on the pull request:

https://github.com/apache/phoenix/pull/156#issuecomment-207677080
  
+1. Looks great, @chrajeshbabu. Thanks for the excellent work.


---
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-2156) Support drop of column from table with views

[Thomas D'Silva (JIRA)]

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

Thomas D'Silva commented on PHOENIX-2156:
-

I will move the tests that require DROP_METADATA_ATTRIB  to a new file.

> Support drop of column from table with views
> 
>
> Key: PHOENIX-2156
> URL: https://issues.apache.org/jira/browse/PHOENIX-2156
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Thomas D'Silva
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2156-v2.patch, PHOENIX-2156-v3.patch, 
> PHOENIX-2156.patch
>
>
> Much like PHOENIX-1504 allows a column to be added to a base view, we should 
> support dropping a column from a table that has views as well. These seems 
> like a simpler problem: you just need to query for all views with a 
> BASE_COLUMN_COUNT < dropped_column_ordinal_pos, decrement the ordinal 
> positions of columns after that, and drop indexes that reference the column 
> being dropped.



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

[jira] [Commented] (PHOENIX-2156) Support drop of column from table with views

[James Taylor (JIRA)]

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

James Taylor commented on PHOENIX-2156:
---

Awesome job, [~tdsilva]. One question: for AlterTableIT and 
AlterTableWithViewsIT, is it necessary to set DROP_METADATA_ATTRIB to true? If 
so, would it be possible to just move the tests that need this to a new test 
file? The reason is that it'll really impact how long it takes to run these 
tests.

> Support drop of column from table with views
> 
>
> Key: PHOENIX-2156
> URL: https://issues.apache.org/jira/browse/PHOENIX-2156
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Thomas D'Silva
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2156-v2.patch, PHOENIX-2156-v3.patch, 
> PHOENIX-2156.patch
>
>
> Much like PHOENIX-1504 allows a column to be added to a base view, we should 
> support dropping a column from a table that has views as well. These seems 
> like a simpler problem: you just need to query for all views with a 
> BASE_COLUMN_COUNT < dropped_column_ordinal_pos, decrement the ordinal 
> positions of columns after that, and drop indexes that reference the column 
> being dropped.



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

Re: [ANNOUNCE] New Apache Phoenix committer - Josh Elser

[Nick Dimiduk]

Nice work! The Josh maffia is growing.

On Friday, April 8, 2016, rajeshb...@apache.org 
wrote:

> Congratulations Josh!!
>
> On Sat, Apr 9, 2016 at 12:17 AM, Ankit Singhal  >
> wrote:
>
> > Congrats Josh!!
> >
> > On Fri, Apr 8, 2016 at 10:29 PM, Marek Wiewiorka <
> > marek.wiewio...@gmail.com >
> > wrote:
> >
> > > Congrats!
> > > 8 kwi 2016 6:57 PM "Josh Mahonin" >
> napisał(a):
> > >
> > > > Welcome aboard and congrats (fellow) Josh!
> > > >
> > > > On Fri, Apr 8, 2016 at 12:52 PM, James Taylor <
> jamestay...@apache.org >
> > > > wrote:
> > > >
> > > > > On behalf of the Apache Phoenix PMC, I'm pleased to announce that
> > Josh
> > > > > Elser has accepted our invitation to become a committer on the
> Apache
> > > > > Phoenix project. He's done an excellent job moving the Phoenix
> Query
> > > > > Server[1] forward, helping us with maven issues, and being an all
> > > around
> > > > > good citizen by answering questions whenever they come up on the
> > > mailing
> > > > > lists and JIRAs.
> > > > >
> > > > > Welcome aboard, Josh. Looking forward to many more contributions!
> > > > >
> > > > > Regards,
> > > > > James
> > > > >
> > > > > [1] https://phoenix.apache.org/server.html
> > > > >
> > > >
> > >
> >
>

[jira] [Commented] (PHOENIX-2535) Create shaded clients (thin + thick)

[Sergey Soldatov (JIRA)]

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

Sergey Soldatov commented on PHOENIX-2535:
--

I've pushed renaming stuff for query server/client in the pull request. 
Also added exclude from shading for avatica.proto. to make PQS working from 
tarball.
[~elserj] speaking about  query server/client dependencies in the 
phoenix-client - we do not ship a separate jar file for PQS, so we run it from 
client jar.


> Create shaded clients (thin + thick) 
> -
>
> Key: PHOENIX-2535
> URL: https://issues.apache.org/jira/browse/PHOENIX-2535
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Sergey Soldatov
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2535-1.patch, PHOENIX-2535-2.patch, 
> PHOENIX-2535-3.patch, PHOENIX-2535-4.patch, PHOENIX-2535-5.patch
>
>
> Having shaded client artifacts helps greatly in minimizing the dependency 
> conflicts at the run time. We are seeing more of Phoenix JDBC client being 
> used in Storm topologies and other settings where guava versions become a 
> problem. 
> I think we can do a parallel artifact for the thick client with shaded 
> dependencies and also using shaded hbase. For thin client, maybe shading 
> should be the default since it is new? 



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

[jira] [Commented] (PHOENIX-2535) Create shaded clients (thin + thick)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2535:
-

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

https://github.com/apache/phoenix/pull/159#discussion_r59098738
  
--- Diff: pom.xml ---
@@ -27,9 +27,11 @@
 phoenix-flume
 phoenix-pig
 phoenix-server-client
-phoenix-server
--- End diff --

Fixed in next commit


> Create shaded clients (thin + thick) 
> -
>
> Key: PHOENIX-2535
> URL: https://issues.apache.org/jira/browse/PHOENIX-2535
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Sergey Soldatov
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2535-1.patch, PHOENIX-2535-2.patch, 
> PHOENIX-2535-3.patch, PHOENIX-2535-4.patch, PHOENIX-2535-5.patch
>
>
> Having shaded client artifacts helps greatly in minimizing the dependency 
> conflicts at the run time. We are seeing more of Phoenix JDBC client being 
> used in Storm topologies and other settings where guava versions become a 
> problem. 
> I think we can do a parallel artifact for the thick client with shaded 
> dependencies and also using shaded hbase. For thin client, maybe shading 
> should be the default since it is new? 



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

[jira] [Commented] (PHOENIX-2535) Create shaded clients (thin + thick)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2535:
-

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

https://github.com/apache/phoenix/pull/159#discussion_r59098717
  
--- Diff: phoenix-server-client/pom.xml ---
@@ -26,29 +26,126 @@
 
   
 ${project.basedir}/..
+org.apache.phoenix.shaded
   
 
   
 
   
-maven-assembly-plugin
-
-  
-thin-client
-package
-
-  single
-
-
-  false
-  phoenix-${project.version}
-  
-src/build/thin-client.xml
-  
-
-  
-
-  
+  maven-assembly-plugin
+  
+true
+  
+
+
+  org.apache.maven.plugins
+  maven-shade-plugin
+  
+
+  thin-client
+  package
+  
+shade
+  
+  
+false
+false
+
true
+false
+phoenix-${project.version}-thin-client
+
> Key: PHOENIX-2535
> URL: https://issues.apache.org/jira/browse/PHOENIX-2535
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Sergey Soldatov
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2535-1.patch, PHOENIX-2535-2.patch, 
> PHOENIX-2535-3.patch, PHOENIX-2535-4.patch, PHOENIX-2535-5.patch
>
>
> Having shaded client artifacts helps greatly in minimizing the dependency 
> conflicts at the run time. We are seeing more of Phoenix JDBC client being 
> used in Storm topologies and other settings where guava versions become a 
> problem. 
> I think we can do a parallel artifact for the thick client with shaded 
> dependencies and also using shaded hbase. For thin client, maybe shading 
> should be the default since it is new? 



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

[GitHub] phoenix pull request: PHOENIX-2535 Create shaded clients (thin + t...

[ss77892]

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

https://github.com/apache/phoenix/pull/159#discussion_r59098738
  
--- Diff: pom.xml ---
@@ -27,9 +27,11 @@
 phoenix-flume
 phoenix-pig
 phoenix-server-client
-phoenix-server
--- End diff --

Fixed in next commit


---
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-2535) Create shaded clients (thin + thick)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2535:
-

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

https://github.com/apache/phoenix/pull/159#discussion_r59098646
  
--- Diff: phoenix-assembly/pom.xml ---
@@ -31,76 +32,30 @@
   phoenix-assembly
   Phoenix Assembly
   Assemble Phoenix artifacts
-  pom
+  jar
--- End diff --

Fixed in next commit


> Create shaded clients (thin + thick) 
> -
>
> Key: PHOENIX-2535
> URL: https://issues.apache.org/jira/browse/PHOENIX-2535
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Sergey Soldatov
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2535-1.patch, PHOENIX-2535-2.patch, 
> PHOENIX-2535-3.patch, PHOENIX-2535-4.patch, PHOENIX-2535-5.patch
>
>
> Having shaded client artifacts helps greatly in minimizing the dependency 
> conflicts at the run time. We are seeing more of Phoenix JDBC client being 
> used in Storm topologies and other settings where guava versions become a 
> problem. 
> I think we can do a parallel artifact for the thick client with shaded 
> dependencies and also using shaded hbase. For thin client, maybe shading 
> should be the default since it is new? 



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

[GitHub] phoenix pull request: PHOENIX-2535 Create shaded clients (thin + t...

[ss77892]

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

https://github.com/apache/phoenix/pull/159#discussion_r59098717
  
--- Diff: phoenix-server-client/pom.xml ---
@@ -26,29 +26,126 @@
 
   
 ${project.basedir}/..
+org.apache.phoenix.shaded
   
 
   
 
   
-maven-assembly-plugin
-
-  
-thin-client
-package
-
-  single
-
-
-  false
-  phoenix-${project.version}
-  
-src/build/thin-client.xml
-  
-
-  
-
-  
+  maven-assembly-plugin
+  
+true
+  
+
+
+  org.apache.maven.plugins
+  maven-shade-plugin
+  
+
+  thin-client
+  package
+  
+shade
+  
+  
+false
+false
+
true
+false
+phoenix-${project.version}-thin-client
+

[GitHub] phoenix pull request: PHOENIX-2535 Create shaded clients (thin + t...

[ss77892]

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

https://github.com/apache/phoenix/pull/159#discussion_r59098646
  
--- Diff: phoenix-assembly/pom.xml ---
@@ -31,76 +32,30 @@
   phoenix-assembly
   Phoenix Assembly
   Assemble Phoenix artifacts
-  pom
+  jar
--- End diff --

Fixed in next commit


---
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-2535) Create shaded clients (thin + thick)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2535:
-

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

https://github.com/apache/phoenix/pull/159#discussion_r59096272
  
--- Diff: pom.xml ---
@@ -27,9 +27,11 @@
 phoenix-flume
 phoenix-pig
 phoenix-server-client
-phoenix-server
--- End diff --

I like the phoenix-queryserver and phoenix-queryserver-client as names of 
the modules. phoenix-server-client is hard to parse without knowing 
phoenix-server is phoenix query server.


> Create shaded clients (thin + thick) 
> -
>
> Key: PHOENIX-2535
> URL: https://issues.apache.org/jira/browse/PHOENIX-2535
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Sergey Soldatov
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2535-1.patch, PHOENIX-2535-2.patch, 
> PHOENIX-2535-3.patch, PHOENIX-2535-4.patch, PHOENIX-2535-5.patch
>
>
> Having shaded client artifacts helps greatly in minimizing the dependency 
> conflicts at the run time. We are seeing more of Phoenix JDBC client being 
> used in Storm topologies and other settings where guava versions become a 
> problem. 
> I think we can do a parallel artifact for the thick client with shaded 
> dependencies and also using shaded hbase. For thin client, maybe shading 
> should be the default since it is new? 



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

[GitHub] phoenix pull request: PHOENIX-2535 Create shaded clients (thin + t...

[enis]

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

https://github.com/apache/phoenix/pull/159#discussion_r59096272
  
--- Diff: pom.xml ---
@@ -27,9 +27,11 @@
 phoenix-flume
 phoenix-pig
 phoenix-server-client
-phoenix-server
--- End diff --

I like the phoenix-queryserver and phoenix-queryserver-client as names of 
the modules. phoenix-server-client is hard to parse without knowing 
phoenix-server is phoenix query server.


---
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] [Resolved] (PHOENIX-2822) Tests that extend BaseHBaseManagedTimeIT are very slow

[Samarth Jain (JIRA)]

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

Samarth Jain resolved PHOENIX-2822.
---
Resolution: Fixed

> Tests that extend BaseHBaseManagedTimeIT are very slow
> --
>
> Key: PHOENIX-2822
> URL: https://issues.apache.org/jira/browse/PHOENIX-2822
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 4.8.0
>Reporter: churro morales
>Assignee: churro morales
>  Labels: HBASEDEPENDENCIES
> Attachments: PHOENIX-2822-98.patch, PHOENIX-2822.patch
>
>
> Since I am trying to refactor out all the hbase private dependencies, I have 
> to constantly run tests to make sure I didn't break anything.  The tests that 
> extend BaseHBaseManagedTimeIT are very slow as they have to delete all 
> non-system tables after every test case.  This takes around 5-10 seconds to 
> accomplish.  This adds significant time to the test suite. 
> I created a new class named: BaseHBaseManagedTimeTableReuseIT and it creates 
> a random table name such that we dont have collisions for tests.  It also 
> doesn't do any cleanup after each test case or class because these table 
> names should be unique.  I moved about 30-35 tests out from 
> BaseHBaseManagedTimeIT to BaseHBaseManagedTimeTableReuseIT and it 
> significantly improved the overall time it takes to run tests.



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

[jira] [Commented] (PHOENIX-2822) Tests that extend BaseHBaseManagedTimeIT are very slow

[Hudson (JIRA)]

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

Hudson commented on PHOENIX-2822:
-

FAILURE: Integrated in Phoenix-master #1189 (See 
[https://builds.apache.org/job/Phoenix-master/1189/])
PHOENIX-2822 Tests that extend BaseHBaseManagedTimeIT are very (samarth: rev 
6d147896f5856e728c454e4a1fa47575d9690aa7)
* phoenix-core/src/it/java/org/apache/phoenix/end2end/StoreNullsIT.java
* phoenix-core/src/it/java/org/apache/phoenix/end2end/QueryMoreIT.java
* phoenix-core/src/it/java/org/apache/phoenix/iterate/PhoenixQueryTimeoutIT.java
* phoenix-core/src/it/java/org/apache/phoenix/end2end/AlterSessionIT.java
* 
phoenix-core/src/it/java/org/apache/phoenix/end2end/salted/SaltedTableVarLengthRowKeyIT.java
* phoenix-core/src/it/java/org/apache/phoenix/end2end/RTrimFunctionIT.java
* phoenix-core/src/it/java/org/apache/phoenix/end2end/AutoCommitIT.java
* phoenix-core/src/it/java/org/apache/phoenix/end2end/AbsFunctionEnd2EndIT.java
* phoenix-core/src/it/java/org/apache/phoenix/end2end/DynamicFamilyIT.java
* 
phoenix-core/src/it/java/org/apache/phoenix/end2end/salted/SaltedTableUpsertSelectIT.java
* phoenix-core/src/it/java/org/apache/phoenix/end2end/LikeExpressionIT.java
* phoenix-core/src/it/java/org/apache/phoenix/end2end/PrimitiveTypeIT.java
* phoenix-core/src/it/java/org/apache/phoenix/end2end/index/DropViewIT.java
* phoenix-core/src/it/java/org/apache/phoenix/end2end/ServerExceptionIT.java
* 
phoenix-core/src/it/java/org/apache/phoenix/end2end/ArrayToStringFunctionIT.java
* 
phoenix-core/src/it/java/org/apache/phoenix/end2end/GetSetByteBitFunctionEnd2EndIT.java
* 
phoenix-core/src/it/java/org/apache/phoenix/end2end/PowerFunctionEnd2EndIT.java
* phoenix-core/src/it/java/org/apache/phoenix/end2end/RegexpSplitFunctionIT.java
* 
phoenix-core/src/it/java/org/apache/phoenix/end2end/UpsertSelectAutoCommitIT.java
* 
phoenix-core/src/it/java/org/apache/phoenix/end2end/MinMaxAggregateFunctionIT.java
* phoenix-core/src/test/java/org/apache/phoenix/memory/MemoryManagerTest.java
* 
phoenix-core/src/it/java/org/apache/phoenix/end2end/TimezoneOffsetFunctionIT.java
* phoenix-core/src/it/java/org/apache/phoenix/end2end/ArraysWithNullsIT.java
* phoenix-core/src/it/java/org/apache/phoenix/end2end/ReverseFunctionIT.java
* phoenix-core/src/it/java/org/apache/phoenix/end2end/MD5FunctionIT.java
* 
phoenix-core/src/it/java/org/apache/phoenix/end2end/MappingTableDataTypeIT.java
* phoenix-core/src/it/java/org/apache/phoenix/end2end/CbrtFunctionEnd2EndIT.java
* 
phoenix-core/src/it/java/org/apache/phoenix/end2end/ConvertTimezoneFunctionIT.java
* 
phoenix-core/src/it/java/org/apache/phoenix/end2end/BaseHBaseManagedTimeIT.java
* phoenix-core/src/it/java/org/apache/phoenix/end2end/ArrayFillFunctionIT.java
* phoenix-core/src/it/java/org/apache/phoenix/end2end/ReadOnlyIT.java
* 
phoenix-core/src/it/java/org/apache/phoenix/end2end/OctetLengthFunctionEnd2EndIT.java
* phoenix-core/src/it/java/org/apache/phoenix/end2end/SortOrderIT.java
* phoenix-core/src/it/java/org/apache/phoenix/end2end/ArithmeticQueryIT.java
* phoenix-core/src/it/java/org/apache/phoenix/end2end/DecodeFunctionIT.java
* phoenix-core/src/it/java/org/apache/phoenix/end2end/StatementHintsIT.java
* 
phoenix-core/src/it/java/org/apache/phoenix/end2end/RoundFloorCeilFunctionsEnd2EndIT.java
* 
phoenix-core/src/it/java/org/apache/phoenix/end2end/BaseHBaseManagedTimeTableReuseIT.java
* 
phoenix-core/src/it/java/org/apache/phoenix/end2end/StringToArrayFunctionIT.java
* phoenix-core/src/it/java/org/apache/phoenix/end2end/SignFunctionEnd2EndIT.java
* phoenix-core/src/test/java/org/apache/phoenix/query/BaseTest.java
* phoenix-core/src/it/java/org/apache/phoenix/end2end/NthValueFunctionIT.java
* phoenix-core/src/main/java/org/apache/phoenix/memory/GlobalMemoryManager.java
* phoenix-core/src/it/java/org/apache/phoenix/end2end/FirstValueFunctionIT.java


> Tests that extend BaseHBaseManagedTimeIT are very slow
> --
>
> Key: PHOENIX-2822
> URL: https://issues.apache.org/jira/browse/PHOENIX-2822
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 4.8.0
>Reporter: churro morales
>Assignee: churro morales
>  Labels: HBASEDEPENDENCIES
> Attachments: PHOENIX-2822-98.patch, PHOENIX-2822.patch
>
>
> Since I am trying to refactor out all the hbase private dependencies, I have 
> to constantly run tests to make sure I didn't break anything.  The tests that 
> extend BaseHBaseManagedTimeIT are very slow as they have to delete all 
> non-system tables after every test case.  This takes around 5-10 seconds to 
> accomplish.  This adds significant time to the test suite. 
> I created a new class named: BaseHBaseManagedTimeTableReuseIT and it creates 
> a random table name such that we dont have collisions for 

[jira] [Commented] (PHOENIX-2535) Create shaded clients (thin + thick)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2535:
-

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

https://github.com/apache/phoenix/pull/159#discussion_r59095759
  
--- Diff: phoenix-server-client/pom.xml ---
@@ -26,29 +26,126 @@
 
   
 ${project.basedir}/..
+org.apache.phoenix.shaded
   
 
   
 
   
-maven-assembly-plugin
-
-  
-thin-client
-package
-
-  single
-
-
-  false
-  phoenix-${project.version}
-  
-src/build/thin-client.xml
-  
-
-  
-
-  
+  maven-assembly-plugin
+  
+true
+  
+
+
+  org.apache.maven.plugins
+  maven-shade-plugin
+  
+
+  thin-client
+  package
+  
+shade
+  
+  
+false
+false
+
true
+false
+phoenix-${project.version}-thin-client
+
> Key: PHOENIX-2535
> URL: https://issues.apache.org/jira/browse/PHOENIX-2535
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Sergey Soldatov
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2535-1.patch, PHOENIX-2535-2.patch, 
> PHOENIX-2535-3.patch, PHOENIX-2535-4.patch, PHOENIX-2535-5.patch
>
>
> Having shaded client artifacts helps greatly in minimizing the dependency 
> conflicts at the run time. We are seeing more of Phoenix JDBC client being 
> used in Storm topologies and other settings where guava versions become a 
> problem. 
> I think we can do a parallel artifact for the thick client with shaded 
> dependencies and also using shaded hbase. For thin client, maybe shading 
> should be the default since it is new? 



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

[GitHub] phoenix pull request: PHOENIX-2535 Create shaded clients (thin + t...

[enis]

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

https://github.com/apache/phoenix/pull/159#discussion_r59095759
  
--- Diff: phoenix-server-client/pom.xml ---
@@ -26,29 +26,126 @@
 
   
 ${project.basedir}/..
+org.apache.phoenix.shaded
   
 
   
 
   
-maven-assembly-plugin
-
-  
-thin-client
-package
-
-  single
-
-
-  false
-  phoenix-${project.version}
-  
-src/build/thin-client.xml
-  
-
-  
-
-  
+  maven-assembly-plugin
+  
+true
+  
+
+
+  org.apache.maven.plugins
+  maven-shade-plugin
+  
+
+  thin-client
+  package
+  
+shade
+  
+  
+false
+false
+
true
+false
+phoenix-${project.version}-thin-client
+

[jira] [Commented] (PHOENIX-2535) Create shaded clients (thin + thick)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2535:
-

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

https://github.com/apache/phoenix/pull/159#discussion_r59095560
  
--- Diff: phoenix-query-server/pom.xml ---
@@ -0,0 +1,116 @@
+http://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
+  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
+  4.0.0
+  
+org.apache.phoenix
+phoenix
+4.8.0-HBase-1.1-SNAPSHOT
+  
+  phoenix-query-server
+  Phoenix Query Server
+  A query server for exposing Phoenix to thin 
clients
+
+  
--- End diff --

these are not coming from the apache parent pom? We only have this in the 
server, not in the client module. 


> Create shaded clients (thin + thick) 
> -
>
> Key: PHOENIX-2535
> URL: https://issues.apache.org/jira/browse/PHOENIX-2535
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Sergey Soldatov
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2535-1.patch, PHOENIX-2535-2.patch, 
> PHOENIX-2535-3.patch, PHOENIX-2535-4.patch, PHOENIX-2535-5.patch
>
>
> Having shaded client artifacts helps greatly in minimizing the dependency 
> conflicts at the run time. We are seeing more of Phoenix JDBC client being 
> used in Storm topologies and other settings where guava versions become a 
> problem. 
> I think we can do a parallel artifact for the thick client with shaded 
> dependencies and also using shaded hbase. For thin client, maybe shading 
> should be the default since it is new? 



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

[jira] [Updated] (PHOENIX-2822) Tests that extend BaseHBaseManagedTimeIT are very slow

[churro morales (JIRA)]

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

churro morales updated PHOENIX-2822:

Attachment: PHOENIX-2822-98.patch

patch for the 98 branch

> Tests that extend BaseHBaseManagedTimeIT are very slow
> --
>
> Key: PHOENIX-2822
> URL: https://issues.apache.org/jira/browse/PHOENIX-2822
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 4.8.0
>Reporter: churro morales
>Assignee: churro morales
>  Labels: HBASEDEPENDENCIES
> Attachments: PHOENIX-2822-98.patch, PHOENIX-2822.patch
>
>
> Since I am trying to refactor out all the hbase private dependencies, I have 
> to constantly run tests to make sure I didn't break anything.  The tests that 
> extend BaseHBaseManagedTimeIT are very slow as they have to delete all 
> non-system tables after every test case.  This takes around 5-10 seconds to 
> accomplish.  This adds significant time to the test suite. 
> I created a new class named: BaseHBaseManagedTimeTableReuseIT and it creates 
> a random table name such that we dont have collisions for tests.  It also 
> doesn't do any cleanup after each test case or class because these table 
> names should be unique.  I moved about 30-35 tests out from 
> BaseHBaseManagedTimeIT to BaseHBaseManagedTimeTableReuseIT and it 
> significantly improved the overall time it takes to run tests.



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

[GitHub] phoenix pull request: PHOENIX-2535 Create shaded clients (thin + t...

[enis]

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

https://github.com/apache/phoenix/pull/159#discussion_r59095560
  
--- Diff: phoenix-query-server/pom.xml ---
@@ -0,0 +1,116 @@
+http://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
+  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
+  4.0.0
+  
+org.apache.phoenix
+phoenix
+4.8.0-HBase-1.1-SNAPSHOT
+  
+  phoenix-query-server
+  Phoenix Query Server
+  A query server for exposing Phoenix to thin 
clients
+
+  
--- End diff --

these are not coming from the apache parent pom? We only have this in the 
server, not in the client module. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] phoenix pull request: PHOENIX-2535 Create shaded clients (thin + t...

[enis]

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

https://github.com/apache/phoenix/pull/159#discussion_r59094621
  
--- Diff: phoenix-assembly/pom.xml ---
@@ -31,76 +32,30 @@
   phoenix-assembly
   Phoenix Assembly
   Assemble Phoenix artifacts
-  pom
+  jar
--- End diff --

hbase-assembly/pom.xml is still pom here. 


---
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-2535) Create shaded clients (thin + thick)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2535:
-

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

https://github.com/apache/phoenix/pull/159#discussion_r59094621
  
--- Diff: phoenix-assembly/pom.xml ---
@@ -31,76 +32,30 @@
   phoenix-assembly
   Phoenix Assembly
   Assemble Phoenix artifacts
-  pom
+  jar
--- End diff --

hbase-assembly/pom.xml is still pom here. 


> Create shaded clients (thin + thick) 
> -
>
> Key: PHOENIX-2535
> URL: https://issues.apache.org/jira/browse/PHOENIX-2535
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Sergey Soldatov
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2535-1.patch, PHOENIX-2535-2.patch, 
> PHOENIX-2535-3.patch, PHOENIX-2535-4.patch, PHOENIX-2535-5.patch
>
>
> Having shaded client artifacts helps greatly in minimizing the dependency 
> conflicts at the run time. We are seeing more of Phoenix JDBC client being 
> used in Storm topologies and other settings where guava versions become a 
> problem. 
> I think we can do a parallel artifact for the thick client with shaded 
> dependencies and also using shaded hbase. For thin client, maybe shading 
> should be the default since it is new? 



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

[jira] [Commented] (PHOENIX-2535) Create shaded clients (thin + thick)

[Nick Dimiduk (JIRA)]

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

Nick Dimiduk commented on PHOENIX-2535:
---

bq. 4.8 RM should especially check whether the publish is going through.

I pointed out in 4.7 release that we don't have publishing to staging repo for 
phoenix. I may have even volunteered to look into it. I don't think there's a 
ticket; we should probably make a blocker for 4.8.

bq. Name these modules as phoenix-queryserver and phoenix-queryserver-client

It's getting verbose, but yeah, that looks about right. Make it explicit.

> Create shaded clients (thin + thick) 
> -
>
> Key: PHOENIX-2535
> URL: https://issues.apache.org/jira/browse/PHOENIX-2535
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Sergey Soldatov
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2535-1.patch, PHOENIX-2535-2.patch, 
> PHOENIX-2535-3.patch, PHOENIX-2535-4.patch, PHOENIX-2535-5.patch
>
>
> Having shaded client artifacts helps greatly in minimizing the dependency 
> conflicts at the run time. We are seeing more of Phoenix JDBC client being 
> used in Storm topologies and other settings where guava versions become a 
> problem. 
> I think we can do a parallel artifact for the thick client with shaded 
> dependencies and also using shaded hbase. For thin client, maybe shading 
> should be the default since it is new? 



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

[jira] [Commented] (PHOENIX-2822) Tests that extend BaseHBaseManagedTimeIT are very slow

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2822:
-

Github user churrodog commented on the pull request:

https://github.com/apache/phoenix/pull/158#issuecomment-207610636
  
@samarthjain rebased and put patch up here: 
https://issues.apache.org/jira/browse/PHOENIX-2822 .  Thanks for the review.


> Tests that extend BaseHBaseManagedTimeIT are very slow
> --
>
> Key: PHOENIX-2822
> URL: https://issues.apache.org/jira/browse/PHOENIX-2822
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 4.8.0
>Reporter: churro morales
>Assignee: churro morales
>  Labels: HBASEDEPENDENCIES
> Attachments: PHOENIX-2822.patch
>
>
> Since I am trying to refactor out all the hbase private dependencies, I have 
> to constantly run tests to make sure I didn't break anything.  The tests that 
> extend BaseHBaseManagedTimeIT are very slow as they have to delete all 
> non-system tables after every test case.  This takes around 5-10 seconds to 
> accomplish.  This adds significant time to the test suite. 
> I created a new class named: BaseHBaseManagedTimeTableReuseIT and it creates 
> a random table name such that we dont have collisions for tests.  It also 
> doesn't do any cleanup after each test case or class because these table 
> names should be unique.  I moved about 30-35 tests out from 
> BaseHBaseManagedTimeIT to BaseHBaseManagedTimeTableReuseIT and it 
> significantly improved the overall time it takes to run tests.



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

[jira] [Updated] (PHOENIX-2822) Tests that extend BaseHBaseManagedTimeIT are very slow

[churro morales (JIRA)]

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

churro morales updated PHOENIX-2822:

Attachment: PHOENIX-2822.patch

here is the rebased patch

> Tests that extend BaseHBaseManagedTimeIT are very slow
> --
>
> Key: PHOENIX-2822
> URL: https://issues.apache.org/jira/browse/PHOENIX-2822
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 4.8.0
>Reporter: churro morales
>Assignee: churro morales
>  Labels: HBASEDEPENDENCIES
> Attachments: PHOENIX-2822.patch
>
>
> Since I am trying to refactor out all the hbase private dependencies, I have 
> to constantly run tests to make sure I didn't break anything.  The tests that 
> extend BaseHBaseManagedTimeIT are very slow as they have to delete all 
> non-system tables after every test case.  This takes around 5-10 seconds to 
> accomplish.  This adds significant time to the test suite. 
> I created a new class named: BaseHBaseManagedTimeTableReuseIT and it creates 
> a random table name such that we dont have collisions for tests.  It also 
> doesn't do any cleanup after each test case or class because these table 
> names should be unique.  I moved about 30-35 tests out from 
> BaseHBaseManagedTimeIT to BaseHBaseManagedTimeTableReuseIT and it 
> significantly improved the overall time it takes to run tests.



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

[GitHub] phoenix pull request: PHOENIX-2822 - Tests that extend BaseHBaseMa...

[churrodog]

Github user churrodog commented on the pull request:

https://github.com/apache/phoenix/pull/158#issuecomment-207610636
  
@samarthjain rebased and put patch up here: 
https://issues.apache.org/jira/browse/PHOENIX-2822 .  Thanks for the review.


---
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-2535) Create shaded clients (thin + thick)

[Enis Soztutar (JIRA)]

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

Enis Soztutar commented on PHOENIX-2535:


bq. Possible we need to rename it to phoenix-query-client as well?
Name these modules as {{phoenix-queryserver}} and 
{{phoenix-queryserver-client}}? 

> Create shaded clients (thin + thick) 
> -
>
> Key: PHOENIX-2535
> URL: https://issues.apache.org/jira/browse/PHOENIX-2535
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Sergey Soldatov
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2535-1.patch, PHOENIX-2535-2.patch, 
> PHOENIX-2535-3.patch, PHOENIX-2535-4.patch, PHOENIX-2535-5.patch
>
>
> Having shaded client artifacts helps greatly in minimizing the dependency 
> conflicts at the run time. We are seeing more of Phoenix JDBC client being 
> used in Storm topologies and other settings where guava versions become a 
> problem. 
> I think we can do a parallel artifact for the thick client with shaded 
> dependencies and also using shaded hbase. For thin client, maybe shading 
> should be the default since it is new? 



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

[jira] [Commented] (PHOENIX-2535) Create shaded clients (thin + thick)

[Enis Soztutar (JIRA)]

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

Enis Soztutar commented on PHOENIX-2535:


bq. Once the dust settles here, it would be great to re-evaluate publishing 
client jars to maven central. It's a real PITA to tell folks doing maven dev to 
drop a jar into their resources manually.
Yes, we are going the maven module route rather than the assembly, so that the 
jars will end up in maven repo. 4.8 RM should especially check whether the 
publish is going through. We can do a a SNAPSHOT publish in the mean time just 
to check. 
bq. I hate to be the bearer of bad news, but these are most likely not meeting 
ASF licensing requirements. For every bundled jar that Phoenix ships in a 
shaded jar, we're going to have to
HBase's shaded modules do the right stuff I think. We can just copy from there. 




> Create shaded clients (thin + thick) 
> -
>
> Key: PHOENIX-2535
> URL: https://issues.apache.org/jira/browse/PHOENIX-2535
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Sergey Soldatov
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2535-1.patch, PHOENIX-2535-2.patch, 
> PHOENIX-2535-3.patch, PHOENIX-2535-4.patch, PHOENIX-2535-5.patch
>
>
> Having shaded client artifacts helps greatly in minimizing the dependency 
> conflicts at the run time. We are seeing more of Phoenix JDBC client being 
> used in Storm topologies and other settings where guava versions become a 
> problem. 
> I think we can do a parallel artifact for the thick client with shaded 
> dependencies and also using shaded hbase. For thin client, maybe shading 
> should be the default since it is new? 



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

[jira] [Commented] (PHOENIX-2535) Create shaded clients (thin + thick)

[Sergey Soldatov (JIRA)]

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

Sergey Soldatov commented on PHOENIX-2535:
--

I created a pull request for easier review.
Changes:
{{phoenix-server}} moved to {{phoenix-query-server}}
{{phoenix-server-client}} is shaded. Possible we need to rename it to 
{{phoenix-query-client}} as well?
I tried to get rid queryserver dependency in the client and move to the 
corresponding modules, but it's really painful. Some mysterious failures during 
connection between client/server without  stack trace. Will dig further while 
this stuff is reviewed. 


> Create shaded clients (thin + thick) 
> -
>
> Key: PHOENIX-2535
> URL: https://issues.apache.org/jira/browse/PHOENIX-2535
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Sergey Soldatov
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2535-1.patch, PHOENIX-2535-2.patch, 
> PHOENIX-2535-3.patch, PHOENIX-2535-4.patch, PHOENIX-2535-5.patch
>
>
> Having shaded client artifacts helps greatly in minimizing the dependency 
> conflicts at the run time. We are seeing more of Phoenix JDBC client being 
> used in Storm topologies and other settings where guava versions become a 
> problem. 
> I think we can do a parallel artifact for the thick client with shaded 
> dependencies and also using shaded hbase. For thin client, maybe shading 
> should be the default since it is new? 



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

[jira] [Commented] (PHOENIX-2535) Create shaded clients (thin + thick)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2535:
-

GitHub user ss77892 opened a pull request:

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

PHOENIX-2535 Create shaded clients (thin + thick)

Shaded client + PHOENIX-2267

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

$ git pull https://github.com/ss77892/phoenix PHOENIX-2535

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

https://github.com/apache/phoenix/pull/159.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 #159


commit a2d87d81a6bcf966f09c578e20569fbb0625d313
Author: Sergey Soldatov 
Date:   2016-04-08T20:54:45Z

PHOENIX-2535 Create shaded clients (thin + thick)




> Create shaded clients (thin + thick) 
> -
>
> Key: PHOENIX-2535
> URL: https://issues.apache.org/jira/browse/PHOENIX-2535
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Sergey Soldatov
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2535-1.patch, PHOENIX-2535-2.patch, 
> PHOENIX-2535-3.patch, PHOENIX-2535-4.patch, PHOENIX-2535-5.patch
>
>
> Having shaded client artifacts helps greatly in minimizing the dependency 
> conflicts at the run time. We are seeing more of Phoenix JDBC client being 
> used in Storm topologies and other settings where guava versions become a 
> problem. 
> I think we can do a parallel artifact for the thick client with shaded 
> dependencies and also using shaded hbase. For thin client, maybe shading 
> should be the default since it is new? 



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

[GitHub] phoenix pull request: PHOENIX-2535 Create shaded clients (thin + t...

[ss77892]

GitHub user ss77892 opened a pull request:

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

PHOENIX-2535 Create shaded clients (thin + thick)

Shaded client + PHOENIX-2267

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

$ git pull https://github.com/ss77892/phoenix PHOENIX-2535

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

https://github.com/apache/phoenix/pull/159.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 #159


commit a2d87d81a6bcf966f09c578e20569fbb0625d313
Author: Sergey Soldatov 
Date:   2016-04-08T20:54:45Z

PHOENIX-2535 Create shaded clients (thin + thick)




---
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] [Updated] (PHOENIX-2156) Support drop of column from table with views

[Thomas D'Silva (JIRA)]

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

Thomas D'Silva updated PHOENIX-2156:

Attachment: PHOENIX-2156-v3.patch

[~jamestaylor]

Thanks for the review. I modified the code to return the tables being dropped 
that are not stored in a shared physical table. I also returned a list of 
shared physical tables to the the client so that the index rows can be deleted 
from the client. 
I also refactored dropColumnsFromChildViews and addRowsToChildViews to pull out 
common code into updateViewHeaderRow. 

In Metadataclient dropColumn we weren't deleting the covered column of the 
index if the column was being dropped from the base table so I fixed this also.
 
{code}
 else if (coveredColumns.contains(columnToDropRef)) {
 String indexColumnName = 
IndexUtil.getIndexColumnName(columnToDrop);
-
indexColumnsToDrop.add(index.getColumn(indexColumnName));
+PColumn indexColumn = 
index.getColumn(indexColumnName);
+indexColumnsToDrop.add(indexColumn);
+// add the index column to be dropped so that we 
actually delete the column values
+columnsToDrop.add(new ColumnRef(new 
TableRef(index), indexColumn.getPosition()));
 }
{code}


> Support drop of column from table with views
> 
>
> Key: PHOENIX-2156
> URL: https://issues.apache.org/jira/browse/PHOENIX-2156
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Thomas D'Silva
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2156-v2.patch, PHOENIX-2156-v3.patch, 
> PHOENIX-2156.patch
>
>
> Much like PHOENIX-1504 allows a column to be added to a base view, we should 
> support dropping a column from a table that has views as well. These seems 
> like a simpler problem: you just need to query for all views with a 
> BASE_COLUMN_COUNT < dropped_column_ordinal_pos, decrement the ordinal 
> positions of columns after that, and drop indexes that reference the column 
> being dropped.



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

[jira] [Commented] (PHOENIX-2822) Tests that extend BaseHBaseManagedTimeIT are very slow

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2822:
-

Github user samarthjain commented on the pull request:

https://github.com/apache/phoenix/pull/158#issuecomment-207594418
  
@churrodog - can you please post a rebased patch on the jira. The current 
patch doesn't apply on master. Thanks!


> Tests that extend BaseHBaseManagedTimeIT are very slow
> --
>
> Key: PHOENIX-2822
> URL: https://issues.apache.org/jira/browse/PHOENIX-2822
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 4.8.0
>Reporter: churro morales
>Assignee: churro morales
>  Labels: HBASEDEPENDENCIES
>
> Since I am trying to refactor out all the hbase private dependencies, I have 
> to constantly run tests to make sure I didn't break anything.  The tests that 
> extend BaseHBaseManagedTimeIT are very slow as they have to delete all 
> non-system tables after every test case.  This takes around 5-10 seconds to 
> accomplish.  This adds significant time to the test suite. 
> I created a new class named: BaseHBaseManagedTimeTableReuseIT and it creates 
> a random table name such that we dont have collisions for tests.  It also 
> doesn't do any cleanup after each test case or class because these table 
> names should be unique.  I moved about 30-35 tests out from 
> BaseHBaseManagedTimeIT to BaseHBaseManagedTimeTableReuseIT and it 
> significantly improved the overall time it takes to run tests.



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

[GitHub] phoenix pull request: PHOENIX-2822 - Tests that extend BaseHBaseMa...

[samarthjain]

Github user samarthjain commented on the pull request:

https://github.com/apache/phoenix/pull/158#issuecomment-207594418
  
@churrodog - can you please post a rebased patch on the jira. The current 
patch doesn't apply on master. 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: PHOENIX-2822 - Tests that extend BaseHBaseMa...

[samarthjain]

Github user samarthjain commented on the pull request:

https://github.com/apache/phoenix/pull/158#issuecomment-207591521
  
Thanks @churrodog. Nice work!


---
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-2822) Tests that extend BaseHBaseManagedTimeIT are very slow

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2822:
-

Github user samarthjain commented on the pull request:

https://github.com/apache/phoenix/pull/158#issuecomment-207591521
  
Thanks @churrodog. Nice work!


> Tests that extend BaseHBaseManagedTimeIT are very slow
> --
>
> Key: PHOENIX-2822
> URL: https://issues.apache.org/jira/browse/PHOENIX-2822
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 4.8.0
>Reporter: churro morales
>Assignee: churro morales
>  Labels: HBASEDEPENDENCIES
>
> Since I am trying to refactor out all the hbase private dependencies, I have 
> to constantly run tests to make sure I didn't break anything.  The tests that 
> extend BaseHBaseManagedTimeIT are very slow as they have to delete all 
> non-system tables after every test case.  This takes around 5-10 seconds to 
> accomplish.  This adds significant time to the test suite. 
> I created a new class named: BaseHBaseManagedTimeTableReuseIT and it creates 
> a random table name such that we dont have collisions for tests.  It also 
> doesn't do any cleanup after each test case or class because these table 
> names should be unique.  I moved about 30-35 tests out from 
> BaseHBaseManagedTimeIT to BaseHBaseManagedTimeTableReuseIT and it 
> significantly improved the overall time it takes to run tests.



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

[jira] [Commented] (PHOENIX-1311) HBase namespaces surfaced in phoenix

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-1311:
-

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

https://github.com/apache/phoenix/pull/153#discussion_r59082461
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/compile/FromCompiler.java ---
@@ -265,12 +332,18 @@ public SingleTableColumnResolver(PhoenixConnection 
connection, NamedTableNode ta
if (def.getColumnDefName().getFamilyName() != null) {
families.add(new 
PColumnFamilyImpl(PNameFactory.newName(def.getColumnDefName().getFamilyName()),Collections.emptyList()));
}
-   }
-   Long scn = connection.getSCN();
-   PTable theTable = new PTableImpl(connection.getTenantId(), 
table.getName().getSchemaName(), table.getName().getTableName(), scn == null ? 
HConstants.LATEST_TIMESTAMP : scn, families);
+}
+Long scn = connection.getSCN();
+String schema = table.getName().getSchemaName();
+if (connection.getSchema() != null) {
--- End diff --

Makes sense. Thanks for the clarification @ankitsinghal 


> HBase namespaces surfaced in phoenix
> 
>
> Key: PHOENIX-1311
> URL: https://issues.apache.org/jira/browse/PHOENIX-1311
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: nicolas maillard
>Assignee: Ankit Singhal
>Priority: Minor
> Fix For: 4.8.0
>
> Attachments: PHOENIX-1311.docx, PHOENIX-1311_v1.patch, 
> PHOENIX-1311_v2.patch, PHOENIX-1311_wip.patch, PHOENIX-1311_wip_2.patch
>
>
> Hbase (HBASE-8015) has the concept of namespaces in the form of 
> myNamespace:MyTable it would be great if Phoenix leveraged this feature to 
> give a database like feature on top of the table.
> Maybe to stay close to Hbase it could also be a create DB:Table...
> or DB.Table which is a more standard annotation?



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

[GitHub] phoenix pull request: PHOENIX-1311 HBase namespaces surfaced in ph...

[samarthjain]

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

https://github.com/apache/phoenix/pull/153#discussion_r59082461
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/compile/FromCompiler.java ---
@@ -265,12 +332,18 @@ public SingleTableColumnResolver(PhoenixConnection 
connection, NamedTableNode ta
if (def.getColumnDefName().getFamilyName() != null) {
families.add(new 
PColumnFamilyImpl(PNameFactory.newName(def.getColumnDefName().getFamilyName()),Collections.emptyList()));
}
-   }
-   Long scn = connection.getSCN();
-   PTable theTable = new PTableImpl(connection.getTenantId(), 
table.getName().getSchemaName(), table.getName().getTableName(), scn == null ? 
HConstants.LATEST_TIMESTAMP : scn, families);
+}
+Long scn = connection.getSCN();
+String schema = table.getName().getSchemaName();
+if (connection.getSchema() != null) {
--- End diff --

Makes sense. Thanks for the clarification @ankitsinghal 


---
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-2628) Ensure split when iterating through results handled correctly

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2628:
-

Github user chrajeshbabu commented on the pull request:

https://github.com/apache/phoenix/pull/156#issuecomment-207582047
  
@JamesRTaylor  Thanks for the review. Committed the changes handling the 
review comments.
Refactored the code and added code comments where ever possible. 

Now not handling the special cases required for ChunkedResultItertor. 

bq. Another potential, different approach would be for Phoenix to 
universally handle the split during scan case (rather than letting the HBase 
client scanner handle it for non aggregate case and Phoenix handle it for the 
aggregate case). Would that simplify things?
Now throwing stale region bound exception all the cases when ever we get 
NSRE then phoenix client can handle the NSRE than hbase client handling with 
wrong region boundaries.

The ordered aggregate queries issue you are mentioning can be handled as 
part of other issue.

Please review the latest code.
Thanks.


> Ensure split when iterating through results handled correctly
> -
>
> Key: PHOENIX-2628
> URL: https://issues.apache.org/jira/browse/PHOENIX-2628
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: Rajeshbabu Chintaguntla
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2628-wip.patch, PHOENIX-2628.patch, 
> PHOENIX-2628_v7.patch, PHOENIX-2628_v8.patch
>
>
> We should start with a test case to ensure this works correctly, both for 
> scans and aggregates.



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

[GitHub] phoenix pull request: PHOENIX-2628 Ensure split when iterating thr...

[chrajeshbabu]

Github user chrajeshbabu commented on the pull request:

https://github.com/apache/phoenix/pull/156#issuecomment-207582047
  
@JamesRTaylor  Thanks for the review. Committed the changes handling the 
review comments.
Refactored the code and added code comments where ever possible. 

Now not handling the special cases required for ChunkedResultItertor. 

bq. Another potential, different approach would be for Phoenix to 
universally handle the split during scan case (rather than letting the HBase 
client scanner handle it for non aggregate case and Phoenix handle it for the 
aggregate case). Would that simplify things?
Now throwing stale region bound exception all the cases when ever we get 
NSRE then phoenix client can handle the NSRE than hbase client handling with 
wrong region boundaries.

The ordered aggregate queries issue you are mentioning can be handled as 
part of other issue.

Please review the latest code.
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.
---

[jira] [Commented] (PHOENIX-1311) HBase namespaces surfaced in phoenix

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-1311:
-

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

https://github.com/apache/phoenix/pull/153#discussion_r59080730
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/compile/FromCompiler.java ---
@@ -265,12 +332,18 @@ public SingleTableColumnResolver(PhoenixConnection 
connection, NamedTableNode ta
if (def.getColumnDefName().getFamilyName() != null) {
families.add(new 
PColumnFamilyImpl(PNameFactory.newName(def.getColumnDefName().getFamilyName()),Collections.emptyList()));
}
-   }
-   Long scn = connection.getSCN();
-   PTable theTable = new PTableImpl(connection.getTenantId(), 
table.getName().getSchemaName(), table.getName().getTableName(), scn == null ? 
HConstants.LATEST_TIMESTAMP : scn, families);
+}
+Long scn = connection.getSCN();
+String schema = table.getName().getSchemaName();
+if (connection.getSchema() != null) {
--- End diff --

Yes, this sounds correct, @ankitsinghal. Thanks for clarifying.


> HBase namespaces surfaced in phoenix
> 
>
> Key: PHOENIX-1311
> URL: https://issues.apache.org/jira/browse/PHOENIX-1311
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: nicolas maillard
>Assignee: Ankit Singhal
>Priority: Minor
> Fix For: 4.8.0
>
> Attachments: PHOENIX-1311.docx, PHOENIX-1311_v1.patch, 
> PHOENIX-1311_v2.patch, PHOENIX-1311_wip.patch, PHOENIX-1311_wip_2.patch
>
>
> Hbase (HBASE-8015) has the concept of namespaces in the form of 
> myNamespace:MyTable it would be great if Phoenix leveraged this feature to 
> give a database like feature on top of the table.
> Maybe to stay close to Hbase it could also be a create DB:Table...
> or DB.Table which is a more standard annotation?



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

[GitHub] phoenix pull request: PHOENIX-1311 HBase namespaces surfaced in ph...

[JamesRTaylor]

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

https://github.com/apache/phoenix/pull/153#discussion_r59080730
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/compile/FromCompiler.java ---
@@ -265,12 +332,18 @@ public SingleTableColumnResolver(PhoenixConnection 
connection, NamedTableNode ta
if (def.getColumnDefName().getFamilyName() != null) {
families.add(new 
PColumnFamilyImpl(PNameFactory.newName(def.getColumnDefName().getFamilyName()),Collections.emptyList()));
}
-   }
-   Long scn = connection.getSCN();
-   PTable theTable = new PTableImpl(connection.getTenantId(), 
table.getName().getSchemaName(), table.getName().getTableName(), scn == null ? 
HConstants.LATEST_TIMESTAMP : scn, families);
+}
+Long scn = connection.getSCN();
+String schema = table.getName().getSchemaName();
+if (connection.getSchema() != null) {
--- End diff --

Yes, this sounds correct, @ankitsinghal. Thanks for clarifying.


---
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-2628) Ensure split when iterating through results handled correctly

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2628:
-

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

https://github.com/apache/phoenix/pull/156#discussion_r59077569
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/BaseScannerRegionObserver.java
 ---
@@ -337,6 +384,22 @@ public boolean nextRaw(List result) throws 
IOException {
 arrayElementCell = 
result.get(arrayElementCellPosition);
 }
 if (ScanUtil.isLocalIndex(scan) && 
!ScanUtil.isAnalyzeTable(scan)) {
--- End diff --

We are getting the results after seek only. Will check once again whether 
we can handle this in local index scanner.


> Ensure split when iterating through results handled correctly
> -
>
> Key: PHOENIX-2628
> URL: https://issues.apache.org/jira/browse/PHOENIX-2628
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: Rajeshbabu Chintaguntla
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2628-wip.patch, PHOENIX-2628.patch, 
> PHOENIX-2628_v7.patch, PHOENIX-2628_v8.patch
>
>
> We should start with a test case to ensure this works correctly, both for 
> scans and aggregates.



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

[GitHub] phoenix pull request: PHOENIX-2628 Ensure split when iterating thr...

[chrajeshbabu]

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

https://github.com/apache/phoenix/pull/156#discussion_r59078097
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/iterate/ChunkedResultIterator.java
 ---
@@ -56,6 +57,7 @@
 private final MutationState mutationState;
 private Scan scan;
 private PeekingResultIterator resultIterator;
+private QueryPlan plan;
 
 public static class ChunkedResultIteratorFactory implements 
ParallelIteratorFactory {
--- End diff --

Currently removed the changes required for ChunkedResultIterator. The 
changes in the chunked result iterator are just removing code not required.


---
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-2628) Ensure split when iterating through results handled correctly

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2628:
-

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

https://github.com/apache/phoenix/pull/156#discussion_r59078097
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/iterate/ChunkedResultIterator.java
 ---
@@ -56,6 +57,7 @@
 private final MutationState mutationState;
 private Scan scan;
 private PeekingResultIterator resultIterator;
+private QueryPlan plan;
 
 public static class ChunkedResultIteratorFactory implements 
ParallelIteratorFactory {
--- End diff --

Currently removed the changes required for ChunkedResultIterator. The 
changes in the chunked result iterator are just removing code not required.


> Ensure split when iterating through results handled correctly
> -
>
> Key: PHOENIX-2628
> URL: https://issues.apache.org/jira/browse/PHOENIX-2628
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: Rajeshbabu Chintaguntla
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2628-wip.patch, PHOENIX-2628.patch, 
> PHOENIX-2628_v7.patch, PHOENIX-2628_v8.patch
>
>
> We should start with a test case to ensure this works correctly, both for 
> scans and aggregates.



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

[jira] [Commented] (PHOENIX-2628) Ensure split when iterating through results handled correctly

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2628:
-

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

https://github.com/apache/phoenix/pull/156#discussion_r59077866
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/GroupedAggregateRegionObserver.java
 ---
@@ -402,8 +405,8 @@ private RegionScanner 
scanUnordered(ObserverContext Ensure split when iterating through results handled correctly
> -
>
> Key: PHOENIX-2628
> URL: https://issues.apache.org/jira/browse/PHOENIX-2628
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: Rajeshbabu Chintaguntla
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2628-wip.patch, PHOENIX-2628.patch, 
> PHOENIX-2628_v7.patch, PHOENIX-2628_v8.patch
>
>
> We should start with a test case to ensure this works correctly, both for 
> scans and aggregates.



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

[GitHub] phoenix pull request: PHOENIX-2628 Ensure split when iterating thr...

[chrajeshbabu]

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

https://github.com/apache/phoenix/pull/156#discussion_r59077866
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/GroupedAggregateRegionObserver.java
 ---
@@ -402,8 +405,8 @@ private RegionScanner 
scanUnordered(ObserverContext

[GitHub] phoenix pull request: PHOENIX-2628 Ensure split when iterating thr...

[chrajeshbabu]

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

https://github.com/apache/phoenix/pull/156#discussion_r59077569
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/BaseScannerRegionObserver.java
 ---
@@ -337,6 +384,22 @@ public boolean nextRaw(List result) throws 
IOException {
 arrayElementCell = 
result.get(arrayElementCellPosition);
 }
 if (ScanUtil.isLocalIndex(scan) && 
!ScanUtil.isAnalyzeTable(scan)) {
--- End diff --

We are getting the results after seek only. Will check once again whether 
we can handle this in local index scanner.


---
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-2628) Ensure split when iterating through results handled correctly

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2628:
-

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

https://github.com/apache/phoenix/pull/156#discussion_r59077319
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/BaseScannerRegionObserver.java
 ---
@@ -279,6 +301,31 @@ protected RegionScanner getWrappedScanner(final 
ObserverContext Ensure split when iterating through results handled correctly
> -
>
> Key: PHOENIX-2628
> URL: https://issues.apache.org/jira/browse/PHOENIX-2628
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: Rajeshbabu Chintaguntla
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2628-wip.patch, PHOENIX-2628.patch, 
> PHOENIX-2628_v7.patch, PHOENIX-2628_v8.patch
>
>
> We should start with a test case to ensure this works correctly, both for 
> scans and aggregates.



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

[jira] [Commented] (PHOENIX-1311) HBase namespaces surfaced in phoenix

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-1311:
-

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

https://github.com/apache/phoenix/pull/153#discussion_r59075136
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/compile/FromCompiler.java ---
@@ -265,12 +332,18 @@ public SingleTableColumnResolver(PhoenixConnection 
connection, NamedTableNode ta
if (def.getColumnDefName().getFamilyName() != null) {
families.add(new 
PColumnFamilyImpl(PNameFactory.newName(def.getColumnDefName().getFamilyName()),Collections.emptyList()));
}
-   }
-   Long scn = connection.getSCN();
-   PTable theTable = new PTableImpl(connection.getTenantId(), 
table.getName().getSchemaName(), table.getName().getTableName(), scn == null ? 
HConstants.LATEST_TIMESTAMP : scn, families);
+}
+Long scn = connection.getSCN();
+String schema = table.getName().getSchemaName();
+if (connection.getSchema() != null) {
--- End diff --

The code in discussion will be used during **creation** of **mapped views** 
only .. It will never be used anywhere else.
So when user provide table name without schema then connection schema 
should be used if set and if user is providing tablename with schema then we 
should ignore connection schema. I think this is how most of the databases work.

for eg:- connection schema is set to 'S' (`phoenix> USE 'S'`)
so , if user create mapped view,
`create view A.T(pk ...)`. //then this will map to A.T table only
`create view T(pk..)` // //then this will map to S.T table

And to map table to default schema (User can unset connection schema back 
to null by using `USE DEFAULT`)
create view T(pk..) // //then this will map to T table

May be I'm missing something, would you mind giving some examples in terms 
of sql statement.


> HBase namespaces surfaced in phoenix
> 
>
> Key: PHOENIX-1311
> URL: https://issues.apache.org/jira/browse/PHOENIX-1311
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: nicolas maillard
>Assignee: Ankit Singhal
>Priority: Minor
> Fix For: 4.8.0
>
> Attachments: PHOENIX-1311.docx, PHOENIX-1311_v1.patch, 
> PHOENIX-1311_v2.patch, PHOENIX-1311_wip.patch, PHOENIX-1311_wip_2.patch
>
>
> Hbase (HBASE-8015) has the concept of namespaces in the form of 
> myNamespace:MyTable it would be great if Phoenix leveraged this feature to 
> give a database like feature on top of the table.
> Maybe to stay close to Hbase it could also be a create DB:Table...
> or DB.Table which is a more standard annotation?



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

Re: [ANNOUNCE] New Apache Phoenix committer - Josh Elser

[rajeshb...@apache.org]

Congratulations Josh!!

On Sat, Apr 9, 2016 at 12:17 AM, Ankit Singhal 
wrote:

> Congrats Josh!!
>
> On Fri, Apr 8, 2016 at 10:29 PM, Marek Wiewiorka <
> marek.wiewio...@gmail.com>
> wrote:
>
> > Congrats!
> > 8 kwi 2016 6:57 PM "Josh Mahonin"  napisał(a):
> >
> > > Welcome aboard and congrats (fellow) Josh!
> > >
> > > On Fri, Apr 8, 2016 at 12:52 PM, James Taylor 
> > > wrote:
> > >
> > > > On behalf of the Apache Phoenix PMC, I'm pleased to announce that
> Josh
> > > > Elser has accepted our invitation to become a committer on the Apache
> > > > Phoenix project. He's done an excellent job moving the Phoenix Query
> > > > Server[1] forward, helping us with maven issues, and being an all
> > around
> > > > good citizen by answering questions whenever they come up on the
> > mailing
> > > > lists and JIRAs.
> > > >
> > > > Welcome aboard, Josh. Looking forward to many more contributions!
> > > >
> > > > Regards,
> > > > James
> > > >
> > > > [1] https://phoenix.apache.org/server.html
> > > >
> > >
> >
>

Re: [ANNOUNCE] New Apache Phoenix committer - Josh Elser

[Ankit Singhal]

Congrats Josh!!

On Fri, Apr 8, 2016 at 10:29 PM, Marek Wiewiorka 
wrote:

> Congrats!
> 8 kwi 2016 6:57 PM "Josh Mahonin"  napisał(a):
>
> > Welcome aboard and congrats (fellow) Josh!
> >
> > On Fri, Apr 8, 2016 at 12:52 PM, James Taylor 
> > wrote:
> >
> > > On behalf of the Apache Phoenix PMC, I'm pleased to announce that Josh
> > > Elser has accepted our invitation to become a committer on the Apache
> > > Phoenix project. He's done an excellent job moving the Phoenix Query
> > > Server[1] forward, helping us with maven issues, and being an all
> around
> > > good citizen by answering questions whenever they come up on the
> mailing
> > > lists and JIRAs.
> > >
> > > Welcome aboard, Josh. Looking forward to many more contributions!
> > >
> > > Regards,
> > > James
> > >
> > > [1] https://phoenix.apache.org/server.html
> > >
> >
>

[jira] [Commented] (PHOENIX-2535) Create shaded clients (thin + thick)

[Josh Elser (JIRA)]

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

Josh Elser commented on PHOENIX-2535:
-

bq. Yep, at the beginning we have discussed what exactly need to be shaded. And 
it seems that phoenix-server-client nobody mentioned. I will add shading for 
this module.

Thanks :). I apologize for arriving late to the party.

> Create shaded clients (thin + thick) 
> -
>
> Key: PHOENIX-2535
> URL: https://issues.apache.org/jira/browse/PHOENIX-2535
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Sergey Soldatov
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2535-1.patch, PHOENIX-2535-2.patch, 
> PHOENIX-2535-3.patch, PHOENIX-2535-4.patch, PHOENIX-2535-5.patch
>
>
> Having shaded client artifacts helps greatly in minimizing the dependency 
> conflicts at the run time. We are seeing more of Phoenix JDBC client being 
> used in Storm topologies and other settings where guava versions become a 
> problem. 
> I think we can do a parallel artifact for the thick client with shaded 
> dependencies and also using shaded hbase. For thin client, maybe shading 
> should be the default since it is new? 



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

[jira] [Commented] (PHOENIX-2535) Create shaded clients (thin + thick)

[Sergey Soldatov (JIRA)]

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

Sergey Soldatov commented on PHOENIX-2535:
--

[~elserj]
{quote}
Ok. Yeah, if we're doing things correctly, the client should never have to have 
the phoenix-[query]server jar's classes. Regarding the thin client jar now, we 
do have a shaded artifact 
(phoenix-server-client/target/phoenix-4.8.0-HBase-1.1-SNAPSHOT-thin-client.jar),
 but the shaded classes aren't relocated. That was the other half of my 
question – did I miss you doing that in your patch? I think that was in the 
original spirit of the JIRA issue's title.
{quote}
Yep, at the beginning we have discussed what exactly need to be shaded. And it 
seems that phoenix-server-client nobody mentioned.  I will add shading for this 
module.



> Create shaded clients (thin + thick) 
> -
>
> Key: PHOENIX-2535
> URL: https://issues.apache.org/jira/browse/PHOENIX-2535
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Sergey Soldatov
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2535-1.patch, PHOENIX-2535-2.patch, 
> PHOENIX-2535-3.patch, PHOENIX-2535-4.patch, PHOENIX-2535-5.patch
>
>
> Having shaded client artifacts helps greatly in minimizing the dependency 
> conflicts at the run time. We are seeing more of Phoenix JDBC client being 
> used in Storm topologies and other settings where guava versions become a 
> problem. 
> I think we can do a parallel artifact for the thick client with shaded 
> dependencies and also using shaded hbase. For thin client, maybe shading 
> should be the default since it is new? 



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

[jira] [Commented] (PHOENIX-2535) Create shaded clients (thin + thick)

[Josh Elser (JIRA)]

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

Josh Elser commented on PHOENIX-2535:
-

bq. phoenix-assembly is generating tarball exactly at the target directory. All 
this stuff is related to the relative path of jars in this tarball. 

Oh, that's my bad. I totally misread the assembly descriptor. Thanks for 
clarifying :)

bq. I don't know whether it's a maven-assembly-plugin specific feature or just 
a bug there, but if we remove those dependencies it will not collect the jar 
dependencies. 

This was about the comment above, specifying the maven-shade-plugin in 
dependencyManagement. Sorry for the confusion.

bq. Well, that was in the original pom.xml at phoenix-assembly which was 
producing client jar, so the client had query server as well as calcite inside. 
I will get rid of it. 

Ok. Yeah, if we're doing things correctly, the client should never have to have 
the phoenix-\[query\]server jar's classes. Regarding the thin client jar now, 
we do have a shaded artifact 
({{phoenix-server-client/target/phoenix-4.8.0-HBase-1.1-SNAPSHOT-thin-client.jar}}),
 but the shaded classes aren't relocated. That was the other half of my 
question -- did I miss you doing that in your patch? I think that was in the 
original spirit of the JIRA issue's title.

bq. And that's exactly that those transforms are doing (or supposed to do). At 
least for licenses in client jar it creates a directory META-INF/license with 
all non ASF license files like:
bq. And we don't have it in the current client jar

Ok. Hopefully this isn't too bad (I'm not sure if these have been looked at 
closely before). Not all people will bundle a LICENSE and NOTICE inside of 
their jar. Sadly, we get screwed by this. After we get a final patch, I can run 
through a build and step through each dependency to make sure we're covered. 
Don't need to hold up your patch for that work (but we should make sure it's 
kosher before making the next release).

(and because I forgot to say it initially) Great work on this. This will be a 
big improvement.

bq. Once the dust settles here, it would be great to re-evaluate publishing 
client jars to maven central. It's a real PITA to tell folks doing maven dev to 
drop a jar into their resources manually.

*huge* +1 to this one, Nick. 

> Create shaded clients (thin + thick) 
> -
>
> Key: PHOENIX-2535
> URL: https://issues.apache.org/jira/browse/PHOENIX-2535
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Sergey Soldatov
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2535-1.patch, PHOENIX-2535-2.patch, 
> PHOENIX-2535-3.patch, PHOENIX-2535-4.patch, PHOENIX-2535-5.patch
>
>
> Having shaded client artifacts helps greatly in minimizing the dependency 
> conflicts at the run time. We are seeing more of Phoenix JDBC client being 
> used in Storm topologies and other settings where guava versions become a 
> problem. 
> I think we can do a parallel artifact for the thick client with shaded 
> dependencies and also using shaded hbase. For thin client, maybe shading 
> should be the default since it is new? 



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

[jira] [Commented] (PHOENIX-2535) Create shaded clients (thin + thick)

[Sergey Soldatov (JIRA)]

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

Sergey Soldatov commented on PHOENIX-2535:
--

[~elserj]
{quote}
Why make this change in phoenix-assembly/pom.xml? It seems like you're just 
working around Maven wanting to create a jar then. If you set this to pom, 
AFAIUI, that should not be trying to create any JAR for the module.
{quote}
Actually not. If set it to pom - it's just create a pom file. The only way I 
have found to disable it - set a non existing phase for {{maven-jar-plugin}}
{quote}
Is there a reason why you aren't putting JARs generated by a module within that 
module's target/ directory? This is really confusing to see in practice "I 
built this module. Where the heck are the artifacts?"
{quote}
{{phoenix-assembly}} is generating tarball exactly at the {{target}} directory. 
All this stuff is related to the relative path of jars in this tarball. 

{quote}
Might be a bit more concise to make a property instead of repeating the shaded 
relocation prefix. E.g. 
org.apache.phoenix.shaded and then 
${shaded.location}.com.fasterxml. Is this more 
concise?
{quote}

sounds reasonable. will do that.

{quote}
This looks unnecessary. The maven-shade-plugin should already be defined in 
pluginManagement in /pom.xml.
{quote}
I don't know whether it's a {{maven-assembly-plugin}} specific feature or just 
a bug there, but if we remove those dependencies it will not collect the jar 
dependencies. 

{quote}
I'm surprised to see phoenix-server and phoenix-server-client in this list. My 
initial thought was that phoenix-client would be a shaded jar for the thick 
driver. Either way, neither thick or thin driver will need phoenix-server.
{quote}
Well, that was in the original {{pom.xml}} at phoenix-assembly which was 
producing client jar, so the client had query server as well as calcite inside. 
I will get rid of it. 

{quote}
I hate to be the bearer of bad news, but these are most likely not meeting ASF 
licensing requirements. For every bundled jar that Phoenix ships in a shaded 
jar, we're going to have to
Copy any NOTICE text into a NOTICE file in the shaded jar
Copy necessary license and copyright information for non-ASLv2 licensed jars 
into a LICENSE file in the shaded jar.
Yes, this will be horrible, but it is required.
{quote}
And that's exactly that those transforms are doing (or supposed to do). At 
least for licenses in client jar it creates a directory {{META-INF/license}} 
with all non ASF license files like:
{noformat}
META-INF//license:
total 176
-rw-r--r--  1 ssoldatov  staff   1592 Apr  7 23:41 LICENSE.base64.txt
-rw-r--r--  1 ssoldatov  staff  10174 Apr  7 23:41 LICENSE.commons-logging.txt
-rw-r--r--  1 ssoldatov  staff  10174 Apr  7 23:41 LICENSE.felix.txt
-rw-r--r--  1 ssoldatov  staff  26441 Apr  7 23:41 LICENSE.jboss-logging.txt
-rw-r--r--  1 ssoldatov  staff   1592 Apr  7 23:41 LICENSE.jsr166y.txt
-rw-r--r--  1 ssoldatov  staff   1465 Apr  7 23:41 LICENSE.jzlib.txt
-rw-r--r--  1 ssoldatov  staff  10174 Apr  7 23:41 LICENSE.log4j.txt
-rw-r--r--  1 ssoldatov  staff   1732 Apr  7 23:41 LICENSE.protobuf.txt
-rw-r--r--  1 ssoldatov  staff   1203 Apr  7 23:41 LICENSE.slf4j.txt
-rw-r--r--  1 ssoldatov  staff   1598 Apr  7 23:41 LICENSE.webbit.txt
{noformat}
And we don't have it in the current client jar :)

> Create shaded clients (thin + thick) 
> -
>
> Key: PHOENIX-2535
> URL: https://issues.apache.org/jira/browse/PHOENIX-2535
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Sergey Soldatov
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2535-1.patch, PHOENIX-2535-2.patch, 
> PHOENIX-2535-3.patch, PHOENIX-2535-4.patch, PHOENIX-2535-5.patch
>
>
> Having shaded client artifacts helps greatly in minimizing the dependency 
> conflicts at the run time. We are seeing more of Phoenix JDBC client being 
> used in Storm topologies and other settings where guava versions become a 
> problem. 
> I think we can do a parallel artifact for the thick client with shaded 
> dependencies and also using shaded hbase. For thin client, maybe shading 
> should be the default since it is new? 



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

[jira] [Commented] (PHOENIX-2822) Tests that extend BaseHBaseManagedTimeIT are very slow

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2822:
-

Github user churrodog commented on the pull request:

https://github.com/apache/phoenix/pull/158#issuecomment-207521158
  
made the changes you requested.


> Tests that extend BaseHBaseManagedTimeIT are very slow
> --
>
> Key: PHOENIX-2822
> URL: https://issues.apache.org/jira/browse/PHOENIX-2822
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 4.8.0
>Reporter: churro morales
>Assignee: churro morales
>  Labels: HBASEDEPENDENCIES
>
> Since I am trying to refactor out all the hbase private dependencies, I have 
> to constantly run tests to make sure I didn't break anything.  The tests that 
> extend BaseHBaseManagedTimeIT are very slow as they have to delete all 
> non-system tables after every test case.  This takes around 5-10 seconds to 
> accomplish.  This adds significant time to the test suite. 
> I created a new class named: BaseHBaseManagedTimeTableReuseIT and it creates 
> a random table name such that we dont have collisions for tests.  It also 
> doesn't do any cleanup after each test case or class because these table 
> names should be unique.  I moved about 30-35 tests out from 
> BaseHBaseManagedTimeIT to BaseHBaseManagedTimeTableReuseIT and it 
> significantly improved the overall time it takes to run tests.



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

[GitHub] phoenix pull request: PHOENIX-2822 - Tests that extend BaseHBaseMa...

[churrodog]

Github user churrodog commented on the pull request:

https://github.com/apache/phoenix/pull/158#issuecomment-207521158
  
made the changes you requested.


---
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] [Resolved] (PHOENIX-2201) Support UNNEST in Phoenix/Calcite integration

[Maryann Xue (JIRA)]

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

Maryann Xue resolved PHOENIX-2201.
--
Resolution: Fixed

> Support UNNEST in Phoenix/Calcite integration
> -
>
> Key: PHOENIX-2201
> URL: https://issues.apache.org/jira/browse/PHOENIX-2201
> Project: Phoenix
>  Issue Type: Task
>Reporter: Maryann Xue
>Assignee: Maryann Xue
>  Labels: calcite
>




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

[jira] [Resolved] (PHOENIX-2203) Support UNNEST WITH ORDINALITY in Calcite-Phoenix

[Maryann Xue (JIRA)]

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

Maryann Xue resolved PHOENIX-2203.
--
Resolution: Fixed

> Support UNNEST WITH ORDINALITY in Calcite-Phoenix
> -
>
> Key: PHOENIX-2203
> URL: https://issues.apache.org/jira/browse/PHOENIX-2203
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: Maryann Xue
>Assignee: Maryann Xue
>  Labels: calcite
>
> Once WITH ORDINALITY is supported in Calcite, we'll be able to add the 
> missing part here in the integration,



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

Re: [ANNOUNCE] New Apache Phoenix committer - Josh Elser

[Marek Wiewiorka]

Congrats!
8 kwi 2016 6:57 PM "Josh Mahonin"  napisał(a):

> Welcome aboard and congrats (fellow) Josh!
>
> On Fri, Apr 8, 2016 at 12:52 PM, James Taylor 
> wrote:
>
> > On behalf of the Apache Phoenix PMC, I'm pleased to announce that Josh
> > Elser has accepted our invitation to become a committer on the Apache
> > Phoenix project. He's done an excellent job moving the Phoenix Query
> > Server[1] forward, helping us with maven issues, and being an all around
> > good citizen by answering questions whenever they come up on the mailing
> > lists and JIRAs.
> >
> > Welcome aboard, Josh. Looking forward to many more contributions!
> >
> > Regards,
> > James
> >
> > [1] https://phoenix.apache.org/server.html
> >
>

Re: [ANNOUNCE] New Apache Phoenix committer - Josh Elser

[Josh Mahonin]

Welcome aboard and congrats (fellow) Josh!

On Fri, Apr 8, 2016 at 12:52 PM, James Taylor 
wrote:

> On behalf of the Apache Phoenix PMC, I'm pleased to announce that Josh
> Elser has accepted our invitation to become a committer on the Apache
> Phoenix project. He's done an excellent job moving the Phoenix Query
> Server[1] forward, helping us with maven issues, and being an all around
> good citizen by answering questions whenever they come up on the mailing
> lists and JIRAs.
>
> Welcome aboard, Josh. Looking forward to many more contributions!
>
> Regards,
> James
>
> [1] https://phoenix.apache.org/server.html
>

[ANNOUNCE] New Apache Phoenix committer - Josh Elser

[James Taylor]

On behalf of the Apache Phoenix PMC, I'm pleased to announce that Josh
Elser has accepted our invitation to become a committer on the Apache
Phoenix project. He's done an excellent job moving the Phoenix Query
Server[1] forward, helping us with maven issues, and being an all around
good citizen by answering questions whenever they come up on the mailing
lists and JIRAs.

Welcome aboard, Josh. Looking forward to many more contributions!

Regards,
James

[1] https://phoenix.apache.org/server.html

[jira] [Commented] (PHOENIX-2535) Create shaded clients (thin + thick)

[Nick Dimiduk (JIRA)]

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

Nick Dimiduk commented on PHOENIX-2535:
---

bq. +1 to rename query server jar

yeah, this should have been fixed before the first release. Whatever you call 
the PQS server jar, be sure the client jar matches so it's super-duper clear 
what's what. And thanks for cleaning up all these thick client jars too, it's 
confusing to see.

Once the dust settles here, it would be great to re-evaluate publishing client 
jars to maven central. It's a real PITA to tell folks doing maven dev to drop a 
jar into their resources manually.

> Create shaded clients (thin + thick) 
> -
>
> Key: PHOENIX-2535
> URL: https://issues.apache.org/jira/browse/PHOENIX-2535
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Sergey Soldatov
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2535-1.patch, PHOENIX-2535-2.patch, 
> PHOENIX-2535-3.patch, PHOENIX-2535-4.patch, PHOENIX-2535-5.patch
>
>
> Having shaded client artifacts helps greatly in minimizing the dependency 
> conflicts at the run time. We are seeing more of Phoenix JDBC client being 
> used in Storm topologies and other settings where guava versions become a 
> problem. 
> I think we can do a parallel artifact for the thick client with shaded 
> dependencies and also using shaded hbase. For thin client, maybe shading 
> should be the default since it is new? 



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

[jira] [Created] (PHOENIX-2829) queryserver fails with InvalidProtocolBufferException when connecting from thinclient

[Eric Daigneault (JIRA)]

Eric Daigneault created PHOENIX-2829:


 Summary: queryserver fails with InvalidProtocolBufferException 
when connecting from thinclient
 Key: PHOENIX-2829
 URL: https://issues.apache.org/jira/browse/PHOENIX-2829
 Project: Phoenix
  Issue Type: Bug
Affects Versions: 4.7.0
 Environment: cluster on Ubuntu 14.04, client app on windows 7

Hadoop 2.7.2, HBase 1.1.3 and Phoenix 4.7.0, cluster with 3 nodes
Reporter: Eric Daigneault


Have a cluster of 3 nodes and was able to perform misc queries and yarn jobs on 
it using just HBase.  Installed Phoenix to get the SQL interface and all worked 
fine with the "fat" client jar in a simple eclipse app.

Was also able to perform querries with SQuirreL and that same client jar 
without issues.

I then tried the thin driver with the queryserver and was never able to get it 
to work.  Squirrel and the simple app return the same error as seen from the 
server's log (see panel below)

The query server runs on the master node which contains the hbase region server 
and the environment variable HBASE_CONF_DIR is set to the folder containing 
hbase-site.xml and other hbase configurations.



{noformat}
java.lang.RuntimeException: 
org.apache.calcite.avatica.com.google.protobuf.InvalidProtocolBufferException: 
While parsing a protocol message, the input ended unexpectedly in the middle of 
a field.  This could mean either that the input has been truncated or that an 
embedded message misreported its own length.
 
at 
org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:98)
   
at 
org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:38)
   
at 
org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:68)

at 
org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)
   
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)  
   
at org.eclipse.jetty.server.Server.handle(Server.java:497)  
  
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
  
at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:245) 
   
at 
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)  
   
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
   
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) 
   
at java.lang.Thread.run(Thread.java:745)
  
Caused by: 
org.apache.calcite.avatica.com.google.protobuf.InvalidProtocolBufferException: 
While parsing a protocol message, the input ended unexpectedly in the middle of 
a field.  This could mean either that the input has been truncated or that an 
embedded message misreported its own length.
  
at 
org.apache.calcite.avatica.com.google.protobuf.InvalidProtocolBufferException.truncatedMessage(InvalidProtocolBufferException.java:70)

   
at 
org.apache.calcite.avatica.com.google.protobuf.CodedInputStream.skipRawBytesSlowPath(CodedInputStream.java:1293)
   
at 
org.apache.calcite.avatica.com.google.protobuf.CodedInputStream.skipRawBytes(CodedInputStream.java:1276)
   
at 
org.apache.calcite.avatica.com.google.protobuf.CodedInputStream.skipField(CodedInputStream.java:197)
   
at 
org.apache.calcite.avatica.com.google.protobuf.CodedInputStream.skipMessage(CodedInputStream.java:273)
 
at 
org.apache.calcite.avatica.com.google.protobuf.CodedInputStream.skipField(CodedInputStream.java:200)
   
at 
org.apache.calcite.avatica.proto.Common$WireMessage.(Common.java:11627)   
   
at 
org.apache.calcite.avatica.proto.Common$WireMessage.(Common.java:11595)   
   
at 
org.apache.calcite.avatica.proto.Common$WireMessage$1.parsePartialFrom(Common.java:12061)
  
at 

[jira] [Commented] (PHOENIX-2535) Create shaded clients (thin + thick)

[Josh Elser (JIRA)]

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

Josh Elser commented on PHOENIX-2535:
-

(sorry, this is getting long. Do we have reviewboard or something set up going 
forward?)

{code}
-  pom
+  jar
{code}

{code}
+default-jar
+none
+
{code}

Why make this change in phoenix-assembly/pom.xml? It seems like you're just 
working around Maven wanting to create a jar then. If you set this to {{pom}}, 
AFAIUI, that should not be trying to create any JAR for the module.

{code}
diff --git a/phoenix-assembly/src/build/components/all-common-jars.xml 
b/phoenix-assembly/src/build/components/all-common-jars.xml
index 960c3c9..f8c5abd 100644
--- a/phoenix-assembly/src/build/components/all-common-jars.xml
+++ b/phoenix-assembly/src/build/components/all-common-jars.xml
@@ -24,12 +24,17 @@
  
 
-  target
+  ${project.basedir}/../phoenix-client/target
   /
   
 phoenix-*-client.jar
+  
+
+
+  ${project.basedir}/../phoenix-server/target
+  /
+  
 phoenix-*-server.jar
-phoenix-*-mapreduce.jar
   
 
 
{code}

Is there a reason why you aren't putting JARs generated by a module within that 
module's target/ directory? This is really confusing to see in practice "I 
built this module. Where the heck are the artifacts?"

{code}
+
+  com.codahale
+  
org.apache.phoenix.shaded.com.codahale
+
+
+  com.fasterxml
+  
org.apache.phoenix.shaded.com.fasterxml
+
{code}

Might be a bit more concise to make a property instead of repeating the shaded 
relocation prefix. E.g. 
{{org.apache.phoenix.shaded}} and then 
{{$\{shaded.location\}.com.fasterxml}}. Is this 
more concise?

{code}
+
+  
+  
+org.apache.maven.plugins
+  maven-shade-plugin
+  
+
+
{code}

This looks unnecessary. The maven-shade-plugin should already be defined in 
pluginManagement in {{/pom.xml}}.

{code}
+  
+
+
+  org.apache.phoenix
+  phoenix-core
+
+
+  org.apache.phoenix
+  phoenix-flume
+
+
+  org.apache.phoenix
+  phoenix-pig
+
+
+  org.apache.phoenix
+  phoenix-spark
+
+
+  org.apache.phoenix
+  phoenix-server
+
+
+  org.apache.phoenix
+  phoenix-server-client
+
+  
{code}

I'm surprised to see phoenix-server and phoenix-server-client in this list. My 
initial thought was that phoenix-client would be a shaded jar for the thick 
driver. Either way, neither thick or thin driver will need phoenix-server.

{code}
+phoenix-client
{code}

Would it better to include the word "shaded" in the module name?

{code}
+  s
+  
+  
+NOTICE
+${project.basedir}/../../NOTICE
+  
...
+  
+LICENSE.txt
+${project.basedir}/../../LICENSE.txt
+  
+
{code}

I hate to be the bearer of bad news, but these are most likely not meeting ASF 
licensing requirements. For every bundled jar that Phoenix ships in a shaded 
jar, we're going to have to

# Copy any NOTICE text into a NOTICE file in the shaded jar
# Copy necessary license and copyright information for non-ASLv2 licensed jars 
into a LICENSE file in the shaded jar.

Yes, this will be horrible, but it is required. 

> Create shaded clients (thin + thick) 
> -
>
> Key: PHOENIX-2535
> URL: https://issues.apache.org/jira/browse/PHOENIX-2535
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Sergey Soldatov
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2535-1.patch, PHOENIX-2535-2.patch, 
> PHOENIX-2535-3.patch, PHOENIX-2535-4.patch, PHOENIX-2535-5.patch
>
>
> Having shaded client artifacts helps greatly in minimizing the dependency 
> conflicts at the run time. We are seeing more of Phoenix JDBC client being 
> used in Storm topologies and other settings where guava versions become a 
> problem. 
> I think we can do a parallel artifact for the thick client with shaded 
> dependencies and also using shaded hbase. For thin client, maybe shading 
> should be the default since it is new? 



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

[jira] [Resolved] (PHOENIX-2828) Ordinality should be 1-based in UNNEST WITH ORDINALITY

[Maryann Xue (JIRA)]

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

Maryann Xue resolved PHOENIX-2828.
--
Resolution: Fixed

Fixed in 
https://git1-us-west.apache.org/repos/asf?p=phoenix.git;a=commit;h=05bae1fbd75a735628abee3f7da09bb0dee1cbb1.

> Ordinality should be 1-based in UNNEST WITH ORDINALITY
> --
>
> Key: PHOENIX-2828
> URL: https://issues.apache.org/jira/browse/PHOENIX-2828
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.7.0
>Reporter: Maryann Xue
>Assignee: Maryann Xue
>Priority: Minor
> Fix For: 4.8.0
>
>




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

[jira] [Created] (PHOENIX-2828) Ordinality should be 1-based in UNNEST WITH ORDINALITY

[Maryann Xue (JIRA)]

Maryann Xue created PHOENIX-2828:


 Summary: Ordinality should be 1-based in UNNEST WITH ORDINALITY
 Key: PHOENIX-2828
 URL: https://issues.apache.org/jira/browse/PHOENIX-2828
 Project: Phoenix
  Issue Type: Bug
Affects Versions: 4.7.0
Reporter: Maryann Xue
Assignee: Maryann Xue
Priority: Minor
 Fix For: 4.8.0






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

[jira] [Created] (PHOENIX-2827) Support OFFSET in Calcite-Phoenix

[Maryann Xue (JIRA)]

Maryann Xue created PHOENIX-2827:


 Summary: Support OFFSET in Calcite-Phoenix
 Key: PHOENIX-2827
 URL: https://issues.apache.org/jira/browse/PHOENIX-2827
 Project: Phoenix
  Issue Type: Task
Reporter: Maryann Xue
Assignee: Maryann Xue






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

[jira] [Updated] (PHOENIX-2203) Support UNNEST WITH ORDINALITY in Calcite-Phoenix

[Maryann Xue (JIRA)]

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

Maryann Xue updated PHOENIX-2203:
-
Summary: Support UNNEST WITH ORDINALITY in Calcite-Phoenix  (was: Track 
Calcite support for WITH ORDINALITY)

> Support UNNEST WITH ORDINALITY in Calcite-Phoenix
> -
>
> Key: PHOENIX-2203
> URL: https://issues.apache.org/jira/browse/PHOENIX-2203
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: Maryann Xue
>Assignee: Maryann Xue
>  Labels: calcite
>
> Once WITH ORDINALITY is supported in Calcite, we'll be able to add the 
> missing part here in the integration,



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

[jira] [Commented] (PHOENIX-2535) Create shaded clients (thin + thick)

[Josh Elser (JIRA)]

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

Josh Elser commented on PHOENIX-2535:
-

bq. I have a suggestion. At the moment there is an ambiguous naming for query 
server and the hbase side jar. They both are phoenix-server and it doesn't look 
good. There is a couple options:

Yeah, this was something that [~apurtell] had pointed out a while back. Let me 
see if I can find it.

It's definitely misleading. Making the PQS jar be "phoenix-queryserver" would 
help. Including "hbase" somewhere in the HBase server-side jar would be 
logical. Both would cause some breakages though. I'm not sure which would be 
better (probably renaming the PQS jar since it's "newer").

> Create shaded clients (thin + thick) 
> -
>
> Key: PHOENIX-2535
> URL: https://issues.apache.org/jira/browse/PHOENIX-2535
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Sergey Soldatov
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2535-1.patch, PHOENIX-2535-2.patch, 
> PHOENIX-2535-3.patch, PHOENIX-2535-4.patch, PHOENIX-2535-5.patch
>
>
> Having shaded client artifacts helps greatly in minimizing the dependency 
> conflicts at the run time. We are seeing more of Phoenix JDBC client being 
> used in Storm topologies and other settings where guava versions become a 
> problem. 
> I think we can do a parallel artifact for the thick client with shaded 
> dependencies and also using shaded hbase. For thin client, maybe shading 
> should be the default since it is new? 



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

[jira] [Commented] (PHOENIX-2722) support mysql "limit,offset" clauses

[Hadoop QA (JIRA)]

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

Hadoop QA commented on PHOENIX-2722:


{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12797577/PHOENIX-2722_v1_rebased.patch
  against master branch at commit 91800b703d9879574ac5b3ee6fcfe6dd73af2148.
  ATTACHMENT ID: 12797577

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

{color:green}+1 tests included{color}.  The patch appears to include 11 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 
24 warning messages.

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

{color:red}-1 lineLengths{color}.  The patch introduces the following lines 
longer than 100:
+query = "SELECT t.eid, t.x + 9 FROM (SELECT entity_id eid, 
b_string b, a_byte + 1 x FROM aTable LIMIT 1 OFFSET 1 ) AS t WHERE t.b = '"
+query = "SELECT t.eid, t.x + 9 FROM (SELECT entity_id eid, 
b_string b, a_byte + 1 x FROM aTable WHERE a_byte + 1 < 9 ) AS t OFFSET 2";
+query = "SELECT t.eid, t.x + 9 FROM (SELECT entity_id eid, 
b_string b, a_byte + 1 x FROM aTable OFFSET 4) AS t WHERE t.b = '"
+query = "SELECT t.c, count(*) FROM (SELECT count(*) c FROM aTable 
GROUP BY a_string) AS t GROUP BY t.c ORDER BY count(*) DESC OFFSET 1";
+String query = "SELECT t.eid FROM (SELECT entity_id eid FROM 
aTable LIMIT 2 OFFSET 1) AS t";
+query = "SELECT t.eid FROM (SELECT entity_id eid FROM aTable LIMIT 
2 OFFSET 1) AS t LIMIT 4 OFFSET 1";
+query = "SELECT t.eid FROM (SELECT entity_id eid FROM aTable LIMIT 
4 OFFSET 1) AS t LIMIT 2";
+query = "SELECT t.eid FROM (SELECT entity_id eid FROM aTable LIMIT 
? OFFSET ?) AS t LIMIT ? OFFSET ?";
+query = "SELECT a, s FROM (SELECT a_string a, sum(a_byte) s FROM 
aTable GROUP BY a_string ORDER BY sum(a_byte) OFFSET 1)";
+query = "SELECT a_string, count(*) FROM (SELECT a_string FROM 
aTable where a_byte < 4 union all SELECT a_string FROM aTable where a_byte > 8 
OFFSET 1) group by a_string";

 {color:red}-1 core tests{color}.  The patch failed these unit tests:
 
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.hbase.index.covered.example.EndToEndCoveredIndexingIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.DeleteIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.MutableIndexIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.CountDistinctCompressionIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.ArithmeticQueryIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.VariableLengthPKIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.QueryTimeoutIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.SpillableGroupByIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.UserDefinedFunctionsIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.IndexMetadataIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.ConnectionUtilIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.MappingTableDataTypeIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.ClientTimeArithmeticQueryIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.MultiCfQueryExecIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.AlterTableIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.CsvBulkLoadToolIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.NativeHBaseTypesIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.MutableIndexFailureIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.ReadOnlyIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.UnionAllIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.ImmutableIndexWithStatsIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.QueryIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.QueryWithLimitIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.ParallelIteratorsIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.TenantSpecificTablesDMLIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.txn.TxWriteFailureIT

[jira] [Commented] (PHOENIX-1311) HBase namespaces surfaced in phoenix

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-1311:
-

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

https://github.com/apache/phoenix/pull/153#discussion_r58994358
  
--- Diff: 
phoenix-core/src/it/java/org/apache/phoenix/tx/TxCheckpointIT.java ---
@@ -96,6 +97,7 @@ public void testUpsertSelectDoesntSeeUpsertedData() 
throws Exception {
 Connection conn = DriverManager.getConnection(getUrl(), props);
 conn.setAutoCommit(true);
 conn.createStatement().execute("CREATE SEQUENCE "+seqName);
+BaseTest.createSchema(getUrl(), fullTableName, null);
--- End diff --

no, this is not needed , I have removed it.


> HBase namespaces surfaced in phoenix
> 
>
> Key: PHOENIX-1311
> URL: https://issues.apache.org/jira/browse/PHOENIX-1311
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: nicolas maillard
>Assignee: Ankit Singhal
>Priority: Minor
> Fix For: 4.8.0
>
> Attachments: PHOENIX-1311.docx, PHOENIX-1311_v1.patch, 
> PHOENIX-1311_v2.patch, PHOENIX-1311_wip.patch, PHOENIX-1311_wip_2.patch
>
>
> Hbase (HBASE-8015) has the concept of namespaces in the form of 
> myNamespace:MyTable it would be great if Phoenix leveraged this feature to 
> give a database like feature on top of the table.
> Maybe to stay close to Hbase it could also be a create DB:Table...
> or DB.Table which is a more standard annotation?



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

[GitHub] phoenix pull request: PHOENIX-1311 HBase namespaces surfaced in ph...

[ankitsinghal]

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

https://github.com/apache/phoenix/pull/153#discussion_r58994358
  
--- Diff: 
phoenix-core/src/it/java/org/apache/phoenix/tx/TxCheckpointIT.java ---
@@ -96,6 +97,7 @@ public void testUpsertSelectDoesntSeeUpsertedData() 
throws Exception {
 Connection conn = DriverManager.getConnection(getUrl(), props);
 conn.setAutoCommit(true);
 conn.createStatement().execute("CREATE SEQUENCE "+seqName);
+BaseTest.createSchema(getUrl(), fullTableName, null);
--- End diff --

no, this is not needed , I have removed 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.
---

[jira] [Commented] (PHOENIX-1311) HBase namespaces surfaced in phoenix

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-1311:
-

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

https://github.com/apache/phoenix/pull/153#discussion_r58994197
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/util/PhoenixRuntime.java ---
@@ -632,6 +645,16 @@ public static ExecutionCommand parseArgs(String[] 
args) {
 return execCmd;
 }
 
+private static String validateTableName(String tableName) {
--- End diff --

no this is to validate during upgrade only, if user is passing tablename 
with ":" by mistake in thought of hbase tablename.


> HBase namespaces surfaced in phoenix
> 
>
> Key: PHOENIX-1311
> URL: https://issues.apache.org/jira/browse/PHOENIX-1311
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: nicolas maillard
>Assignee: Ankit Singhal
>Priority: Minor
> Fix For: 4.8.0
>
> Attachments: PHOENIX-1311.docx, PHOENIX-1311_v1.patch, 
> PHOENIX-1311_v2.patch, PHOENIX-1311_wip.patch, PHOENIX-1311_wip_2.patch
>
>
> Hbase (HBASE-8015) has the concept of namespaces in the form of 
> myNamespace:MyTable it would be great if Phoenix leveraged this feature to 
> give a database like feature on top of the table.
> Maybe to stay close to Hbase it could also be a create DB:Table...
> or DB.Table which is a more standard annotation?



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

[GitHub] phoenix pull request: PHOENIX-1311 HBase namespaces surfaced in ph...

[ankitsinghal]

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

https://github.com/apache/phoenix/pull/153#discussion_r58994197
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/util/PhoenixRuntime.java ---
@@ -632,6 +645,16 @@ public static ExecutionCommand parseArgs(String[] 
args) {
 return execCmd;
 }
 
+private static String validateTableName(String tableName) {
--- End diff --

no this is to validate during upgrade only, if user is passing tablename 
with ":" by mistake in thought of hbase tablename.


---
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-1311) HBase namespaces surfaced in phoenix

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-1311:
-

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

https://github.com/apache/phoenix/pull/153#discussion_r58994035
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/schema/stats/StatisticsCollectorFactory.java
 ---
@@ -63,6 +64,10 @@ public static StatisticsCollector 
createStatisticsCollector(
 
DISABLE_STATS.add(TableName.valueOf(PhoenixDatabaseMetaData.SYSTEM_FUNCTION_NAME));
 
DISABLE_STATS.add(TableName.valueOf(PhoenixDatabaseMetaData.SYSTEM_SEQUENCE_NAME));
 
DISABLE_STATS.add(TableName.valueOf(PhoenixDatabaseMetaData.SYSTEM_STATS_NAME));
+
DISABLE_STATS.add(SchemaUtil.getPhysicalTableName(PhoenixDatabaseMetaData.SYSTEM_CATALOG_NAME_BYTES,true));
--- End diff --

same as above, it just to avoid collecting stats for system table, so list 
contains both.


> HBase namespaces surfaced in phoenix
> 
>
> Key: PHOENIX-1311
> URL: https://issues.apache.org/jira/browse/PHOENIX-1311
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: nicolas maillard
>Assignee: Ankit Singhal
>Priority: Minor
> Fix For: 4.8.0
>
> Attachments: PHOENIX-1311.docx, PHOENIX-1311_v1.patch, 
> PHOENIX-1311_v2.patch, PHOENIX-1311_wip.patch, PHOENIX-1311_wip_2.patch
>
>
> Hbase (HBASE-8015) has the concept of namespaces in the form of 
> myNamespace:MyTable it would be great if Phoenix leveraged this feature to 
> give a database like feature on top of the table.
> Maybe to stay close to Hbase it could also be a create DB:Table...
> or DB.Table which is a more standard annotation?



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

[GitHub] phoenix pull request: PHOENIX-1311 HBase namespaces surfaced in ph...

[ankitsinghal]

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

https://github.com/apache/phoenix/pull/153#discussion_r58994035
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/schema/stats/StatisticsCollectorFactory.java
 ---
@@ -63,6 +64,10 @@ public static StatisticsCollector 
createStatisticsCollector(
 
DISABLE_STATS.add(TableName.valueOf(PhoenixDatabaseMetaData.SYSTEM_FUNCTION_NAME));
 
DISABLE_STATS.add(TableName.valueOf(PhoenixDatabaseMetaData.SYSTEM_SEQUENCE_NAME));
 
DISABLE_STATS.add(TableName.valueOf(PhoenixDatabaseMetaData.SYSTEM_STATS_NAME));
+
DISABLE_STATS.add(SchemaUtil.getPhysicalTableName(PhoenixDatabaseMetaData.SYSTEM_CATALOG_NAME_BYTES,true));
--- End diff --

same as above, it just to avoid collecting stats for system table, so list 
contains both.


---
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-1311) HBase namespaces surfaced in phoenix

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-1311:
-

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

https://github.com/apache/phoenix/pull/153#discussion_r58993926
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/schema/PTableKey.java ---
@@ -26,7 +28,8 @@
 public PTableKey(PName tenantId, String name) {
 Preconditions.checkNotNull(name);
 this.tenantId = tenantId;
-this.name = name;
+this.name = !name.contains(QueryConstants.NAMESPACE_SEPARATOR) ? 
name
--- End diff --

We are still maintaining phoenix table name(A.B) in cache. so that's why if 
by mistake physical table is passed as a key , it should be resolve correctly. 
I think I just kept this for precaution only. LocalIndexIT/ViewIndexIT covers 
it right?


> HBase namespaces surfaced in phoenix
> 
>
> Key: PHOENIX-1311
> URL: https://issues.apache.org/jira/browse/PHOENIX-1311
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: nicolas maillard
>Assignee: Ankit Singhal
>Priority: Minor
> Fix For: 4.8.0
>
> Attachments: PHOENIX-1311.docx, PHOENIX-1311_v1.patch, 
> PHOENIX-1311_v2.patch, PHOENIX-1311_wip.patch, PHOENIX-1311_wip_2.patch
>
>
> Hbase (HBASE-8015) has the concept of namespaces in the form of 
> myNamespace:MyTable it would be great if Phoenix leveraged this feature to 
> give a database like feature on top of the table.
> Maybe to stay close to Hbase it could also be a create DB:Table...
> or DB.Table which is a more standard annotation?



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

[GitHub] phoenix pull request: PHOENIX-1311 HBase namespaces surfaced in ph...

[ankitsinghal]

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

https://github.com/apache/phoenix/pull/153#discussion_r58993926
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/schema/PTableKey.java ---
@@ -26,7 +28,8 @@
 public PTableKey(PName tenantId, String name) {
 Preconditions.checkNotNull(name);
 this.tenantId = tenantId;
-this.name = name;
+this.name = !name.contains(QueryConstants.NAMESPACE_SEPARATOR) ? 
name
--- End diff --

We are still maintaining phoenix table name(A.B) in cache. so that's why if 
by mistake physical table is passed as a key , it should be resolve correctly. 
I think I just kept this for precaution only. LocalIndexIT/ViewIndexIT covers 
it 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: PHOENIX-1311 HBase namespaces surfaced in ph...

[ankitsinghal]

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

https://github.com/apache/phoenix/pull/153#discussion_r58993453
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/schema/MetaDataClient.java ---
@@ -631,7 +664,7 @@ private boolean 
addIndexesFromPhysicalTable(MetaDataMutationResult result, Long
 if (view.getType() != PTableType.VIEW || view.getViewType() == 
ViewType.MAPPED) {
 return false;
 }
-String physicalName = view.getPhysicalName().getString();
+String physicalName = view.getPhysicalNames().get(0).toString();
--- End diff --

Yes, we don't support views over multiple tables that's why I used get(0) 
only. But I have undo it by modifying the other api's to resolve schema and 
table-name correctly even if namespace separator is present. like 
SchemaUtil.getTableNameFromFullName()


---
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-1311) HBase namespaces surfaced in phoenix

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-1311:
-

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

https://github.com/apache/phoenix/pull/153#discussion_r58993453
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/schema/MetaDataClient.java ---
@@ -631,7 +664,7 @@ private boolean 
addIndexesFromPhysicalTable(MetaDataMutationResult result, Long
 if (view.getType() != PTableType.VIEW || view.getViewType() == 
ViewType.MAPPED) {
 return false;
 }
-String physicalName = view.getPhysicalName().getString();
+String physicalName = view.getPhysicalNames().get(0).toString();
--- End diff --

Yes, we don't support views over multiple tables that's why I used get(0) 
only. But I have undo it by modifying the other api's to resolve schema and 
table-name correctly even if namespace separator is present. like 
SchemaUtil.getTableNameFromFullName()


> HBase namespaces surfaced in phoenix
> 
>
> Key: PHOENIX-1311
> URL: https://issues.apache.org/jira/browse/PHOENIX-1311
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: nicolas maillard
>Assignee: Ankit Singhal
>Priority: Minor
> Fix For: 4.8.0
>
> Attachments: PHOENIX-1311.docx, PHOENIX-1311_v1.patch, 
> PHOENIX-1311_v2.patch, PHOENIX-1311_wip.patch, PHOENIX-1311_wip_2.patch
>
>
> Hbase (HBASE-8015) has the concept of namespaces in the form of 
> myNamespace:MyTable it would be great if Phoenix leveraged this feature to 
> give a database like feature on top of the table.
> Maybe to stay close to Hbase it could also be a create DB:Table...
> or DB.Table which is a more standard annotation?



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

[jira] [Commented] (PHOENIX-1311) HBase namespaces surfaced in phoenix

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-1311:
-

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

https://github.com/apache/phoenix/pull/153#discussion_r58992390
  
--- Diff: 
phoenix-core/src/main/java/org/apache/hadoop/hbase/ipc/controller/MetadataRpcController.java
 ---
@@ -36,7 +37,16 @@
.add(PhoenixDatabaseMetaData.SYSTEM_CATALOG_NAME)
.add(PhoenixDatabaseMetaData.SYSTEM_STATS_NAME)
.add(PhoenixDatabaseMetaData.SYSTEM_SEQUENCE_NAME)
-   
.add(PhoenixDatabaseMetaData.SYSTEM_FUNCTION_NAME).build();
+   .add(PhoenixDatabaseMetaData.SYSTEM_FUNCTION_NAME)
+
.add(SchemaUtil.getPhysicalTableName(PhoenixDatabaseMetaData.SYSTEM_CATALOG_NAME_BYTES,
 true)
--- End diff --

yeah, namespace mapping for system tables will not always be true as it is 
controlled with phoenix.connection.mapSystemTablesToNamespace, 
but this is just the list of system tables, so it includes SYSTEM.CATAOG 
and SYSTEM:CATALOG both to set the priority for RPC accordingly. 
do you think, it could have any impact?


> HBase namespaces surfaced in phoenix
> 
>
> Key: PHOENIX-1311
> URL: https://issues.apache.org/jira/browse/PHOENIX-1311
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: nicolas maillard
>Assignee: Ankit Singhal
>Priority: Minor
> Fix For: 4.8.0
>
> Attachments: PHOENIX-1311.docx, PHOENIX-1311_v1.patch, 
> PHOENIX-1311_v2.patch, PHOENIX-1311_wip.patch, PHOENIX-1311_wip_2.patch
>
>
> Hbase (HBASE-8015) has the concept of namespaces in the form of 
> myNamespace:MyTable it would be great if Phoenix leveraged this feature to 
> give a database like feature on top of the table.
> Maybe to stay close to Hbase it could also be a create DB:Table...
> or DB.Table which is a more standard annotation?



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

[GitHub] phoenix pull request: PHOENIX-1311 HBase namespaces surfaced in ph...

[ankitsinghal]

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

https://github.com/apache/phoenix/pull/153#discussion_r58992390
  
--- Diff: 
phoenix-core/src/main/java/org/apache/hadoop/hbase/ipc/controller/MetadataRpcController.java
 ---
@@ -36,7 +37,16 @@
.add(PhoenixDatabaseMetaData.SYSTEM_CATALOG_NAME)
.add(PhoenixDatabaseMetaData.SYSTEM_STATS_NAME)
.add(PhoenixDatabaseMetaData.SYSTEM_SEQUENCE_NAME)
-   
.add(PhoenixDatabaseMetaData.SYSTEM_FUNCTION_NAME).build();
+   .add(PhoenixDatabaseMetaData.SYSTEM_FUNCTION_NAME)
+
.add(SchemaUtil.getPhysicalTableName(PhoenixDatabaseMetaData.SYSTEM_CATALOG_NAME_BYTES,
 true)
--- End diff --

yeah, namespace mapping for system tables will not always be true as it is 
controlled with phoenix.connection.mapSystemTablesToNamespace, 
but this is just the list of system tables, so it includes SYSTEM.CATAOG 
and SYSTEM:CATALOG both to set the priority for RPC accordingly. 
do you think, it could have any impact?


---
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-1311) HBase namespaces surfaced in phoenix

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-1311:
-

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

https://github.com/apache/phoenix/pull/153#discussion_r58991938
  
--- Diff: 
phoenix-core/src/it/java/org/apache/phoenix/end2end/QueryDatabaseMetaDataIT.java
 ---
@@ -190,14 +190,8 @@ public void testSchemaMetadataScan() throws 
SQLException {
 
 rs = dbmd.getSchemas(null, null);
 assertTrue(rs.next());
-assertEquals(rs.getString("TABLE_SCHEM"),null);
--- End diff --

As now , we will show only those schemas which are created with "create 
schema" command and having table as empty string. so null is not expected


> HBase namespaces surfaced in phoenix
> 
>
> Key: PHOENIX-1311
> URL: https://issues.apache.org/jira/browse/PHOENIX-1311
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: nicolas maillard
>Assignee: Ankit Singhal
>Priority: Minor
> Fix For: 4.8.0
>
> Attachments: PHOENIX-1311.docx, PHOENIX-1311_v1.patch, 
> PHOENIX-1311_v2.patch, PHOENIX-1311_wip.patch, PHOENIX-1311_wip_2.patch
>
>
> Hbase (HBASE-8015) has the concept of namespaces in the form of 
> myNamespace:MyTable it would be great if Phoenix leveraged this feature to 
> give a database like feature on top of the table.
> Maybe to stay close to Hbase it could also be a create DB:Table...
> or DB.Table which is a more standard annotation?



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

[GitHub] phoenix pull request: PHOENIX-1311 HBase namespaces surfaced in ph...

[ankitsinghal]

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

https://github.com/apache/phoenix/pull/153#discussion_r58991938
  
--- Diff: 
phoenix-core/src/it/java/org/apache/phoenix/end2end/QueryDatabaseMetaDataIT.java
 ---
@@ -190,14 +190,8 @@ public void testSchemaMetadataScan() throws 
SQLException {
 
 rs = dbmd.getSchemas(null, null);
 assertTrue(rs.next());
-assertEquals(rs.getString("TABLE_SCHEM"),null);
--- End diff --

As now , we will show only those schemas which are created with "create 
schema" command and having table as empty string. so null is not expected


---
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-1311) HBase namespaces surfaced in phoenix

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-1311:
-

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

https://github.com/apache/phoenix/pull/153#discussion_r58990926
  
--- Diff: 
phoenix-core/src/it/java/org/apache/phoenix/tx/TxCheckpointIT.java ---
@@ -96,6 +97,7 @@ public void testUpsertSelectDoesntSeeUpsertedData() 
throws Exception {
 Connection conn = DriverManager.getConnection(getUrl(), props);
 conn.setAutoCommit(true);
 conn.createStatement().execute("CREATE SEQUENCE "+seqName);
+BaseTest.createSchema(getUrl(), fullTableName, null);
--- End diff --

Is this change needed?


> HBase namespaces surfaced in phoenix
> 
>
> Key: PHOENIX-1311
> URL: https://issues.apache.org/jira/browse/PHOENIX-1311
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: nicolas maillard
>Assignee: Ankit Singhal
>Priority: Minor
> Fix For: 4.8.0
>
> Attachments: PHOENIX-1311.docx, PHOENIX-1311_v1.patch, 
> PHOENIX-1311_v2.patch, PHOENIX-1311_wip.patch, PHOENIX-1311_wip_2.patch
>
>
> Hbase (HBASE-8015) has the concept of namespaces in the form of 
> myNamespace:MyTable it would be great if Phoenix leveraged this feature to 
> give a database like feature on top of the table.
> Maybe to stay close to Hbase it could also be a create DB:Table...
> or DB.Table which is a more standard annotation?



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

[GitHub] phoenix pull request: PHOENIX-1311 HBase namespaces surfaced in ph...

[samarthjain]

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

https://github.com/apache/phoenix/pull/153#discussion_r58990926
  
--- Diff: 
phoenix-core/src/it/java/org/apache/phoenix/tx/TxCheckpointIT.java ---
@@ -96,6 +97,7 @@ public void testUpsertSelectDoesntSeeUpsertedData() 
throws Exception {
 Connection conn = DriverManager.getConnection(getUrl(), props);
 conn.setAutoCommit(true);
 conn.createStatement().execute("CREATE SEQUENCE "+seqName);
+BaseTest.createSchema(getUrl(), fullTableName, null);
--- End diff --

Is this change 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-1311) HBase namespaces surfaced in phoenix

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-1311:
-

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

https://github.com/apache/phoenix/pull/153#discussion_r58990747
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/util/PhoenixRuntime.java ---
@@ -632,6 +645,16 @@ public static ExecutionCommand parseArgs(String[] 
args) {
 return execCmd;
 }
 
+private static String validateTableName(String tableName) {
--- End diff --

Looking at this method it seems like table names can't have : in them. Does 
the change in PTableKey.java still make sense then?


> HBase namespaces surfaced in phoenix
> 
>
> Key: PHOENIX-1311
> URL: https://issues.apache.org/jira/browse/PHOENIX-1311
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: nicolas maillard
>Assignee: Ankit Singhal
>Priority: Minor
> Fix For: 4.8.0
>
> Attachments: PHOENIX-1311.docx, PHOENIX-1311_v1.patch, 
> PHOENIX-1311_v2.patch, PHOENIX-1311_wip.patch, PHOENIX-1311_wip_2.patch
>
>
> Hbase (HBASE-8015) has the concept of namespaces in the form of 
> myNamespace:MyTable it would be great if Phoenix leveraged this feature to 
> give a database like feature on top of the table.
> Maybe to stay close to Hbase it could also be a create DB:Table...
> or DB.Table which is a more standard annotation?



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

[GitHub] phoenix pull request: PHOENIX-1311 HBase namespaces surfaced in ph...

[samarthjain]

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

https://github.com/apache/phoenix/pull/153#discussion_r58990747
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/util/PhoenixRuntime.java ---
@@ -632,6 +645,16 @@ public static ExecutionCommand parseArgs(String[] 
args) {
 return execCmd;
 }
 
+private static String validateTableName(String tableName) {
--- End diff --

Looking at this method it seems like table names can't have : in them. Does 
the change in PTableKey.java still make sense 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-1311) HBase namespaces surfaced in phoenix

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-1311:
-

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

https://github.com/apache/phoenix/pull/153#discussion_r58990594
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/schema/stats/StatisticsCollectorFactory.java
 ---
@@ -63,6 +64,10 @@ public static StatisticsCollector 
createStatisticsCollector(
 
DISABLE_STATS.add(TableName.valueOf(PhoenixDatabaseMetaData.SYSTEM_FUNCTION_NAME));
 
DISABLE_STATS.add(TableName.valueOf(PhoenixDatabaseMetaData.SYSTEM_SEQUENCE_NAME));
 
DISABLE_STATS.add(TableName.valueOf(PhoenixDatabaseMetaData.SYSTEM_STATS_NAME));
+
DISABLE_STATS.add(SchemaUtil.getPhysicalTableName(PhoenixDatabaseMetaData.SYSTEM_CATALOG_NAME_BYTES,true));
--- End diff --

Same as in the other place. Is name space mapping always true?


> HBase namespaces surfaced in phoenix
> 
>
> Key: PHOENIX-1311
> URL: https://issues.apache.org/jira/browse/PHOENIX-1311
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: nicolas maillard
>Assignee: Ankit Singhal
>Priority: Minor
> Fix For: 4.8.0
>
> Attachments: PHOENIX-1311.docx, PHOENIX-1311_v1.patch, 
> PHOENIX-1311_v2.patch, PHOENIX-1311_wip.patch, PHOENIX-1311_wip_2.patch
>
>
> Hbase (HBASE-8015) has the concept of namespaces in the form of 
> myNamespace:MyTable it would be great if Phoenix leveraged this feature to 
> give a database like feature on top of the table.
> Maybe to stay close to Hbase it could also be a create DB:Table...
> or DB.Table which is a more standard annotation?



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

[GitHub] phoenix pull request: PHOENIX-1311 HBase namespaces surfaced in ph...

[samarthjain]

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

https://github.com/apache/phoenix/pull/153#discussion_r58990594
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/schema/stats/StatisticsCollectorFactory.java
 ---
@@ -63,6 +64,10 @@ public static StatisticsCollector 
createStatisticsCollector(
 
DISABLE_STATS.add(TableName.valueOf(PhoenixDatabaseMetaData.SYSTEM_FUNCTION_NAME));
 
DISABLE_STATS.add(TableName.valueOf(PhoenixDatabaseMetaData.SYSTEM_SEQUENCE_NAME));
 
DISABLE_STATS.add(TableName.valueOf(PhoenixDatabaseMetaData.SYSTEM_STATS_NAME));
+
DISABLE_STATS.add(SchemaUtil.getPhysicalTableName(PhoenixDatabaseMetaData.SYSTEM_CATALOG_NAME_BYTES,true));
--- End diff --

Same as in the other place. Is name space mapping always true?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] phoenix pull request: PHOENIX-1311 HBase namespaces surfaced in ph...

[samarthjain]

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

https://github.com/apache/phoenix/pull/153#discussion_r58990540
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/schema/PTableKey.java ---
@@ -26,7 +28,8 @@
 public PTableKey(PName tenantId, String name) {
 Preconditions.checkNotNull(name);
 this.tenantId = tenantId;
-this.name = name;
+this.name = !name.contains(QueryConstants.NAMESPACE_SEPARATOR) ? 
name
--- End diff --

So if the table name was A:B, the key would become A.B. Can you add some 
test case around this and make sure creating, query, upserting to a table named 
like this works fine.


---
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-1311) HBase namespaces surfaced in phoenix

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-1311:
-

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

https://github.com/apache/phoenix/pull/153#discussion_r58989689
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/schema/MetaDataClient.java ---
@@ -631,7 +664,7 @@ private boolean 
addIndexesFromPhysicalTable(MetaDataMutationResult result, Long
 if (view.getType() != PTableType.VIEW || view.getViewType() == 
ViewType.MAPPED) {
 return false;
 }
-String physicalName = view.getPhysicalName().getString();
+String physicalName = view.getPhysicalNames().get(0).toString();
--- End diff --

Please undo this change as we still don't allow creating views over 
multiple tables.


> HBase namespaces surfaced in phoenix
> 
>
> Key: PHOENIX-1311
> URL: https://issues.apache.org/jira/browse/PHOENIX-1311
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: nicolas maillard
>Assignee: Ankit Singhal
>Priority: Minor
> Fix For: 4.8.0
>
> Attachments: PHOENIX-1311.docx, PHOENIX-1311_v1.patch, 
> PHOENIX-1311_v2.patch, PHOENIX-1311_wip.patch, PHOENIX-1311_wip_2.patch
>
>
> Hbase (HBASE-8015) has the concept of namespaces in the form of 
> myNamespace:MyTable it would be great if Phoenix leveraged this feature to 
> give a database like feature on top of the table.
> Maybe to stay close to Hbase it could also be a create DB:Table...
> or DB.Table which is a more standard annotation?



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

[GitHub] phoenix pull request: PHOENIX-1311 HBase namespaces surfaced in ph...

[samarthjain]

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

https://github.com/apache/phoenix/pull/153#discussion_r58989689
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/schema/MetaDataClient.java ---
@@ -631,7 +664,7 @@ private boolean 
addIndexesFromPhysicalTable(MetaDataMutationResult result, Long
 if (view.getType() != PTableType.VIEW || view.getViewType() == 
ViewType.MAPPED) {
 return false;
 }
-String physicalName = view.getPhysicalName().getString();
+String physicalName = view.getPhysicalNames().get(0).toString();
--- End diff --

Please undo this change as we still don't allow creating views over 
multiple tables.


---
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-1311) HBase namespaces surfaced in phoenix

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-1311:
-

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

https://github.com/apache/phoenix/pull/153#discussion_r58989498
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/query/QueryServicesOptions.java 
---
@@ -133,11 +135,13 @@
 // latency and client-side spooling/buffering. Smaller means less 
initial
 // latency and less parallelization.
 public static final long DEFAULT_SCAN_RESULT_CHUNK_SIZE = 2999;
+public static final boolean DEFAULT_IS_NAMESPACE_MAPPING_ENABLED = 
false;
+public static final boolean 
DEFAULT_IS_SYSTEM_TABLE_MAPPED_TO_NAMESPACE = false;
 
 //
 // Spillable GroupBy - SPGBY prefix
 //
-// Enable / disable spillable group by
+// Enable / disablfalsellable group by
--- End diff --

Please undo.


> HBase namespaces surfaced in phoenix
> 
>
> Key: PHOENIX-1311
> URL: https://issues.apache.org/jira/browse/PHOENIX-1311
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: nicolas maillard
>Assignee: Ankit Singhal
>Priority: Minor
> Fix For: 4.8.0
>
> Attachments: PHOENIX-1311.docx, PHOENIX-1311_v1.patch, 
> PHOENIX-1311_v2.patch, PHOENIX-1311_wip.patch, PHOENIX-1311_wip_2.patch
>
>
> Hbase (HBASE-8015) has the concept of namespaces in the form of 
> myNamespace:MyTable it would be great if Phoenix leveraged this feature to 
> give a database like feature on top of the table.
> Maybe to stay close to Hbase it could also be a create DB:Table...
> or DB.Table which is a more standard annotation?



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

[GitHub] phoenix pull request: PHOENIX-1311 HBase namespaces surfaced in ph...

[samarthjain]

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

https://github.com/apache/phoenix/pull/153#discussion_r58989498
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/query/QueryServicesOptions.java 
---
@@ -133,11 +135,13 @@
 // latency and client-side spooling/buffering. Smaller means less 
initial
 // latency and less parallelization.
 public static final long DEFAULT_SCAN_RESULT_CHUNK_SIZE = 2999;
+public static final boolean DEFAULT_IS_NAMESPACE_MAPPING_ENABLED = 
false;
+public static final boolean 
DEFAULT_IS_SYSTEM_TABLE_MAPPED_TO_NAMESPACE = false;
 
 //
 // Spillable GroupBy - SPGBY prefix
 //
-// Enable / disable spillable group by
+// Enable / disablfalsellable group by
--- End diff --

Please undo.


---
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-1311) HBase namespaces surfaced in phoenix

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-1311:
-

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

https://github.com/apache/phoenix/pull/153#discussion_r58989392
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java
 ---
@@ -2387,8 +2452,27 @@ public Void call() throws Exception {
 logger.info("Update of SYSTEM.CATALOG 
complete");

clearCache();
 }
-
+
+if (currentServerSideTableTimeStamp < 
MetaDataProtocol.MIN_SYSTEM_TABLE_TIMESTAMP_4_8_0) {
+// Add these columns one at a time, 
each with different timestamps so that if folks
--- End diff --

Please remove this comment as it doesn't make sense here.


> HBase namespaces surfaced in phoenix
> 
>
> Key: PHOENIX-1311
> URL: https://issues.apache.org/jira/browse/PHOENIX-1311
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: nicolas maillard
>Assignee: Ankit Singhal
>Priority: Minor
> Fix For: 4.8.0
>
> Attachments: PHOENIX-1311.docx, PHOENIX-1311_v1.patch, 
> PHOENIX-1311_v2.patch, PHOENIX-1311_wip.patch, PHOENIX-1311_wip_2.patch
>
>
> Hbase (HBASE-8015) has the concept of namespaces in the form of 
> myNamespace:MyTable it would be great if Phoenix leveraged this feature to 
> give a database like feature on top of the table.
> Maybe to stay close to Hbase it could also be a create DB:Table...
> or DB.Table which is a more standard annotation?



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

[GitHub] phoenix pull request: PHOENIX-1311 HBase namespaces surfaced in ph...

[samarthjain]

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

https://github.com/apache/phoenix/pull/153#discussion_r58989392
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java
 ---
@@ -2387,8 +2452,27 @@ public Void call() throws Exception {
 logger.info("Update of SYSTEM.CATALOG 
complete");

clearCache();
 }
-
+
+if (currentServerSideTableTimeStamp < 
MetaDataProtocol.MIN_SYSTEM_TABLE_TIMESTAMP_4_8_0) {
+// Add these columns one at a time, 
each with different timestamps so that if folks
--- End diff --

Please remove this comment as it doesn't make sense here.


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