Re: Continuing Trace UI work?

[Ayola Jayamaha]

Thanks Jesse,

For you ideas, Yes we can more focus in to zipkin

On Thu, Mar 24, 2016 at 1:07 AM, Jesse Yates  wrote:

> I sent this to James the other day, didn't get a chance to post it on the
> JIRA yet:
>
> *I was poking around htrace and zipkin and it looks like zipkin has a jdbc
> storage plugin.

By default, the ZipKin storage for traces is embedded SQLite engine


> Might be a nice little piece of work to integrate phoenix
> into that - would act as storage for the zipkin collector (rather than
> cassandra/mysql) and query interface. It might be nice to just use zipkin's
> UI with HTrace spans all the way

+1

> and rip out our tracing server.*
>
> On Wed, Mar 23, 2016 at 10:56 AM Ayola Jayamaha 
> wrote:
>
> > Hi All,
> >
> > I am drafting my GSOC 2016 proposal. As it is done I will share with you
> > all.
> > I went through all jiras regard "phoenix trace UI"  and I brainstorm them
> > for proposal. I am going to handle main two task
> >
> > 1. Phoenix trace web app : Finalize and bring it where users can used
> >
> >- Fixing all jira on there
> >- Some improvements
> >- Standardize it to industrial (using Bower and Grunt)
> >
> > Last week I was looking some other Apache projects who do they handle JS,
> > web app in java repos.
> >
> > 2.  Bring Zipkin into the Phoenix Trace
> >
> >- I try some genrated tracing on Zipkin
> >- Zipkin Architecture is feasible to integrate for  phoenix
> >   -  Same time need some code level changes and I will work on them
> >   with support of Phoenix and Zipkin communities
> >
> > User can used any tracing app depending on their user case,
> >
> > you ideas are well come.
> >
> > On Wed, Mar 16, 2016 at 12:08 AM, Ayola Jayamaha  >
> > wrote:
> >
> >> That is great,
> >> I knew some in Zipkin (A. Cole) as I demo phoenix trace app for them
> last
> >> time. I can get some help from them for to understand Zipkin  if any
> need
> >> for  Jira1119.
> >>
> >>
> >>
> >> On Tue, Mar 15, 2016 at 11:47 PM, James Taylor 
> >> wrote:
> >>
> >>> Yes, definitely.
> >>>
> >>> On Tue, Mar 15, 2016 at 11:09 AM, Ayola Jayamaha <
> raphaelan...@gmail.com
> >>> > wrote:
> >>>
>  Hi James,
> 
>  Is [1] considered in GSoC 2016?
> 
>  [1] https://issues.apache.org/jira/browse/PHOENIX-1119
> 
> 
> 
>  On Sat, Mar 12, 2016 at 11:38 PM, Ayola Jayamaha <
>  raphaelan...@gmail.com> wrote:
> 
> > Thanks James
> >
> >  I will go each of them.
> >
> > On Thu, Mar 10, 2016 at 11:39 PM, James Taylor <
> jamestay...@apache.org
> > > wrote:
> >
> >> Sounds great. Take a look at PHOENIX-2701 [1] and its subtasks. To
> >> see all outstanding tracing work, make a look at all JIRAs with a
> "tracing"
> >> label [2].
> >>
> >> Thanks,
> >> James
> >>
> >> [1] https://issues.apache.org/jira/browse/PHOENIX-2701
> >> [2]
> >>
> https://issues.apache.org/jira/browse/PHOENIX-2701?jql=project%20%3D%20PHOENIX%20AND%20resolution%20%3D%20Unresolved%20and%20labels%3D%22tracing%22
> >>
> >> On Thu, Mar 10, 2016 at 6:29 AM, Ayola Jayamaha <
> >> raphaelan...@gmail.com> wrote:
> >>
> >>> Hi,
> >>> I didn't plan to participate in GSoC again. But since the results
> >>> are still pending and I am doing a research at the University I
> thought of
> >>> participating in GSoC again.
> >>>
> >>> If that's fine I can think few more things to improve tracing web
> >>> app and create some jira. I can make a proposal for GSoC 2016 if
> it's
> >>> alright. And I like to work with the community since I am familiar
> with
> >>> them.
> >>>
> >>> Thanks.
> >>>
> >>> On Wed, Mar 9, 2016 at 1:05 PM, James Taylor <
> jamestay...@apache.org
> >>> > wrote:
> >>>
>  Sounds good - will you be participating in the GSoC program again
>  this year?
> 
>  On Tue, Mar 8, 2016 at 6:46 AM, Ayola Jayamaha <
>  raphaelan...@gmail.com> wrote:
> 
> > Hi James,
> >
> > Yes everything is fine. University results are still pending(it's
> > normal in Sri Lanka :) ).
> >
> > I am interested in moving forward with tracing in Phoenix if it's
> > fine.
> > We can try to improve the tracing web app and get it release.
> >
> > Thanks,
> > Nishani
> >
> > On Mon, Mar 7, 2016 at 1:59 AM, James Taylor <
> > jamestay...@apache.org> wrote:
> >
> >> Hi Nishani,
> >> How's everything going? GSoC is starting up again. Any interest
> >> in moving the tracing work forward in Phoenix?
> >> Regards,
> >> James
> >>
> >> On Wed, Nov 11, 2015 at 11:54 PM, James Taylor <
> >> jamestay...@apache.org> wrote:
> >>
> >>> 

[jira] [Commented] (PHOENIX-2541) Support addBatch() and updateBatch() through QueryServer

[Josh Elser (JIRA)]

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

Josh Elser commented on PHOENIX-2541:
-

This just landed in Avatica 1.8.0. Will likely get a release cut up there in 
the next few weeks. After that, we'll automatically get that functionality here.

One other thing I was thinking about was updating pherf to have an option to 
use the addBatch/updateBatch APIs. Will throw up a patch for that ahead of time.

> Support addBatch() and updateBatch() through QueryServer
> 
>
> Key: PHOENIX-2541
> URL: https://issues.apache.org/jira/browse/PHOENIX-2541
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 4.6.0
>Reporter: YoungWoo Kim
>Assignee: Josh Elser
>
> It would be very useful if Phoenix supports addBatch() and updateBatch() for 
> thin driver(QueryServer)



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

[jira] [Commented] (PHOENIX-2714) Correct byte estimate in BaseResultIterators and expose as interface

[Maryann Xue (JIRA)]

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

Maryann Xue commented on PHOENIX-2714:
--

Let's target it for next release.

> Correct byte estimate in BaseResultIterators and expose as interface
> 
>
> Key: PHOENIX-2714
> URL: https://issues.apache.org/jira/browse/PHOENIX-2714
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.7.0
>Reporter: Maryann Xue
>Assignee: Maryann Xue
>  Labels: statistics
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2714.patch
>
>
> The bytes are accumulated even if the range intersect is empty (produces a 
> null scan).
> {code}
> while (guideIndex < gpsSize && 
> (currentGuidePost.compareTo(endKey) <= 0 || endKey.length == 0)) {
> Scan newScan = scanRanges.intersectScan(scan, 
> currentKeyBytes, currentGuidePostBytes, keyOffset,
> false);
> estimatedRows += gps.getRowCounts().get(guideIndex);
> estimatedSize += gps.getByteCounts().get(guideIndex);
> scans = addNewScan(parallelScans, scans, newScan, 
> currentGuidePostBytes, false, regionLocation);
> currentKeyBytes = currentGuidePost.copyBytes();
> currentGuidePost = PrefixByteCodec.decode(decoder, input);
> currentGuidePostBytes = currentGuidePost.copyBytes();
> guideIndex++;
> }
> {code}



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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2722:
-

Github user maryannxue commented on the pull request:

https://github.com/apache/phoenix/pull/154#issuecomment-200637757
  
@ankitsinghal Thank you very much for the pull request! I am impressed by 
how many details you have taken into account in your commit. It took me quite a 
while to go through all of the changes. That said, it would be great if you 
could add more test cases covering most (if not all) of the code changes, e.g. 
the join case (left outer join w/ offset and w/wo limit), the derived table 
case, the join with subquery case, etc.

Check JoinCompiler.isFlat(SelectStatement), it returns true only when limit 
== null, think it should be the same for offset. That function is called when a 
join contains a subquery, e.g. "select * from (select a, b from t1 offset 3) 
join (select c, d from t2 limit 10)".


> support mysql "limit,offset" clauses 
> -
>
> Key: PHOENIX-2722
> URL: https://issues.apache.org/jira/browse/PHOENIX-2722
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Minor
> Attachments: PHOENIX-2722.patch, PHOENIX-2722_formatted.patch
>
>
> For serial query(query with “serial" hint or  “limit" without "order by”), we 
> can limit each scan(using page filter) to “limit+offset” instead of limit 
> earlier.
> And then, for all queries, we can forward the relevant client iterators to 
> the offset provided and then return the result.
> syntax
> {code}
> [ LIMIT { count } ]
> [ OFFSET start [ ROW | ROWS ] ]
> [ FETCH { FIRST | NEXT } [ count ] { ROW | ROWS } ONLY ]
> {code}
> Some new keywords(OFFSET,FETCH,ROW, ROWS,ONLY) are getting introduced so 
> users might need to see that they are not using them as column name or 
> something.
> WDYT, [~jamestaylor]



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

[GitHub] phoenix pull request: PHOENIX-2722 support mysql limit,offset clau...

[maryannxue]

Github user maryannxue commented on the pull request:

https://github.com/apache/phoenix/pull/154#issuecomment-200637757
  
@ankitsinghal Thank you very much for the pull request! I am impressed by 
how many details you have taken into account in your commit. It took me quite a 
while to go through all of the changes. That said, it would be great if you 
could add more test cases covering most (if not all) of the code changes, e.g. 
the join case (left outer join w/ offset and w/wo limit), the derived table 
case, the join with subquery case, etc.

Check JoinCompiler.isFlat(SelectStatement), it returns true only when limit 
== null, think it should be the same for offset. That function is called when a 
join contains a subquery, e.g. "select * from (select a, b from t1 offset 3) 
join (select c, d from t2 limit 10)".


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

Re: GSoC - 2016

[Pranavan Theivendiram]

Hi James.

Thanks for the feedback. I will do necessary changes.

Thanks

*T. Pranavan*
*BSc Eng Undergraduate| Department of Computer Science & Engineering
,University of Moratuwa*
*Mobile| *0775136836

On 23 March 2016 at 21:19, James Taylor  wrote:

> Looks very good, Pranavan. Mujtaba & Rajeshbabu - would you mind giving
> this a quick review as well?
>
> Thanks,
> James
>
> On Wed, Mar 23, 2016 at 5:55 AM, Pranavan Theivendiram <
> pranavan...@cse.mrt.ac.lk> wrote:
>
>> Hi Taylor,
>>
>> Kind remainder.
>>
>> Thanks
>>
>> *T. Pranavan*
>> *BSc Eng Undergraduate| Department of Computer Science & Engineering
>> ,University of Moratuwa*
>> *Mobile| *0775136836
>>
>> On 22 March 2016 at 23:00, Pranavan Theivendiram <
>> pranavan...@cse.mrt.ac.lk> wrote:
>>
>>> Hi Taylor,
>>>
>>> Please give me some comments regarding my proposal. Draft proposal link
>>> is given below.
>>>
>>> Link -
>>> https://docs.google.com/a/cse.mrt.ac.lk/document/d/1eDJIdy5m4oX5tX4xH0mW4e3AEx9r1jyuZRZTl7-rXO4/edit?usp=sharing
>>>
>>> Thanks
>>>
>>> *T. Pranavan*
>>> *BSc Eng Undergraduate| Department of Computer Science & Engineering
>>> ,University of Moratuwa*
>>> *Mobile| *0775136836
>>>
>>> On 20 March 2016 at 08:44, Pranavan Theivendiram <
>>> pranavan...@cse.mrt.ac.lk> wrote:
>>>
 Thanks Zhang

 *T. Pranavan*
 *BSc Eng Undergraduate| Department of Computer Science & Engineering
 ,University of Moratuwa*
 *Mobile| *0775136836

 On 20 March 2016 at 01:12, Zhang, Haoran  wrote:

> Hi Pranavan,
>
> Here  is the template
> provided by Apache.
>
> Hope it helps.
>
> --
>
> Kind regards,
>
>
> Haoran Zhang
>
> 在 March 19, 2016 03:30:55, Pranavan Theivendiram (
> pranavan...@cse.mrt.ac.lk) 写到:
>
> Hi James,
>
> Do you have any template that I have to follow to write the proposal?
> ( I
> am writing in a GDoC and will share with you today.)
>
> Thanks
>
> *T. Pranavan*
> *BSc Eng Undergraduate| Department of Computer Science & Engineering
> ,University of Moratuwa*
> *Mobile| *0775136836
>
> On 18 March 2016 at 12:22, James Taylor 
> wrote:
>
> > Great! I think PHOENIX-1121 is a good one - there's plenty of work
> there to
> > keep you occupied for the whole time. I think PHOENIX-1178 is a bit
> too
> > undefined to include at this point.
> >
> > Thanks,
> >
> > James
> >
> > On Thu, Mar 17, 2016 at 11:07 PM, Pranavan Theivendiram <
> > pranavan...@cse.mrt.ac.lk> wrote:
> >
> > > Hi James,
> > >
> > > I went through some of the jira issues. The following two issues
> are
> > > interesting for me. I have some experience in the past. Hence, it
> will be
> > > handy for me. Please let me know, if anyone is working on these
> issues.
> > >
> > > 1178 - https://issues.apache.org/jira/browse/PHOENIX-1178
> > > 1121 - https://issues.apache.org/jira/browse/PHOENIX-1121
> > >
> > > Thanks
> > >
> > > *T. Pranavan*
> > > *BSc Eng Undergraduate| Department of Computer Science &
> Engineering
> > > ,University of Moratuwa*
> > > *Mobile| *0775136836
> > >
> > > On 18 March 2016 at 11:26, Pranavan Theivendiram <
> > > pranavan...@cse.mrt.ac.lk> wrote:
> > >
> > >> Thanks James. I will have look at possible JIRAS and get back to
> you
> > ASAP.
> > >>
> > >> Thanks
> > >>
> > >> *T. Pranavan*
> > >> *BSc Eng Undergraduate| Department of Computer Science &
> Engineering
> > >> ,University of Moratuwa*
> > >> *Mobile| *0775136836
> > >>
> > >> On 18 March 2016 at 11:18, James Taylor 
> wrote:
> > >>
> > >>> Yes, I'd recommend choosing multiple JIRAs.
> > >>>
> > >>>
> > >>> On Thursday, March 17, 2016, Pranavan Theivendiram <
> > >>> pranavan...@cse.mrt.ac.lk> wrote:
> > >>>
> >  Hi James,
> > 
> >  As per the comment from RamKrishna, the issue is a stability
> issue. Do
> >  I have to look at some other issue?
> > 
> >  Thanks
> > 
> >  *T. Pranavan*
> >  *BSc Eng Undergraduate| Department of Computer Science &
> Engineering
> >  ,University of Moratuwa*
> >  *Mobile| *0775136836
> > 
> >  On 18 March 2016 at 10:08, Pranavan Theivendiram <
> >  pranavan...@cse.mrt.ac.lk> wrote:
> > 
> > > Hi James,
> > >
> > > JIRA - https://issues.apache.org/jira/browse/PHOENIX-2405
> > >
> > > Ramkrishna is commented that he is looking into this issue.
> Are you
> > > going to remove GSoC2016 label from this jira issue?
> > >
> > > Please 

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2722:
-

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

https://github.com/apache/phoenix/pull/154#discussion_r57269833
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/compile/QueryCompiler.java ---
@@ -324,10 +328,13 @@ protected QueryPlan compileJoinQuery(StatementContext 
context, List bind
 QueryPlan plan = compileSingleFlatQuery(context, query, binds, 
asSubquery, !asSubquery && joinTable.isAllLeftJoin(), null, 
!table.isSubselect() && projectPKColumns ? tupleProjector : null, true);
 Expression postJoinFilterExpression = 
joinTable.compilePostFilterExpression(context, table);
 Integer limit = null;
+Integer offset = null;
 if (!query.isAggregate() && !query.isDistinct() && 
query.getOrderBy().isEmpty()) {
 limit = plan.getLimit();
+offset = plan.getOffset();
 }
-HashJoinInfo joinInfo = new HashJoinInfo(projectedTable, 
joinIds, joinExpressions, joinTypes, starJoinVector, tables, fieldPositions, 
postJoinFilterExpression, limit);
+HashJoinInfo joinInfo = new HashJoinInfo(projectedTable, 
joinIds, joinExpressions, joinTypes,
+starJoinVector, tables, fieldPositions, 
postJoinFilterExpression, limit, offset);
--- End diff --

The "limit" in HashJoinInfo is a little different than the original SQL 
semantics. It specifies the max number of rows returned by a 
HashJoinRegionScanner so that it doesn't do too much unnecessary work, and its 
max rows per region, so in the end the client might get more rows than needed 
and will do a final limit operation (all done by ScanPlan, don't worry). So, 
here, I think the limit should be "offset + limit" and there is no need to add 
an extra "offset" field to HashJoinInfo. Btw, change in 
serialization/deserialization of HashJoinInfo would cause incompatibility 
between different versions.


> support mysql "limit,offset" clauses 
> -
>
> Key: PHOENIX-2722
> URL: https://issues.apache.org/jira/browse/PHOENIX-2722
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Minor
> Attachments: PHOENIX-2722.patch, PHOENIX-2722_formatted.patch
>
>
> For serial query(query with “serial" hint or  “limit" without "order by”), we 
> can limit each scan(using page filter) to “limit+offset” instead of limit 
> earlier.
> And then, for all queries, we can forward the relevant client iterators to 
> the offset provided and then return the result.
> syntax
> {code}
> [ LIMIT { count } ]
> [ OFFSET start [ ROW | ROWS ] ]
> [ FETCH { FIRST | NEXT } [ count ] { ROW | ROWS } ONLY ]
> {code}
> Some new keywords(OFFSET,FETCH,ROW, ROWS,ONLY) are getting introduced so 
> users might need to see that they are not using them as column name or 
> something.
> WDYT, [~jamestaylor]



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

[GitHub] phoenix pull request: PHOENIX-2722 support mysql limit,offset clau...

[maryannxue]

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

https://github.com/apache/phoenix/pull/154#discussion_r57269833
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/compile/QueryCompiler.java ---
@@ -324,10 +328,13 @@ protected QueryPlan compileJoinQuery(StatementContext 
context, List bind
 QueryPlan plan = compileSingleFlatQuery(context, query, binds, 
asSubquery, !asSubquery && joinTable.isAllLeftJoin(), null, 
!table.isSubselect() && projectPKColumns ? tupleProjector : null, true);
 Expression postJoinFilterExpression = 
joinTable.compilePostFilterExpression(context, table);
 Integer limit = null;
+Integer offset = null;
 if (!query.isAggregate() && !query.isDistinct() && 
query.getOrderBy().isEmpty()) {
 limit = plan.getLimit();
+offset = plan.getOffset();
 }
-HashJoinInfo joinInfo = new HashJoinInfo(projectedTable, 
joinIds, joinExpressions, joinTypes, starJoinVector, tables, fieldPositions, 
postJoinFilterExpression, limit);
+HashJoinInfo joinInfo = new HashJoinInfo(projectedTable, 
joinIds, joinExpressions, joinTypes,
+starJoinVector, tables, fieldPositions, 
postJoinFilterExpression, limit, offset);
--- End diff --

The "limit" in HashJoinInfo is a little different than the original SQL 
semantics. It specifies the max number of rows returned by a 
HashJoinRegionScanner so that it doesn't do too much unnecessary work, and its 
max rows per region, so in the end the client might get more rows than needed 
and will do a final limit operation (all done by ScanPlan, don't worry). So, 
here, I think the limit should be "offset + limit" and there is no need to add 
an extra "offset" field to HashJoinInfo. Btw, change in 
serialization/deserialization of HashJoinInfo would cause incompatibility 
between different versions.


---
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-2722) support mysql "limit,offset" clauses

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on PHOENIX-2722:
-

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

https://github.com/apache/phoenix/pull/154#discussion_r57269271
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/compile/SubselectRewriter.java ---
@@ -202,14 +204,30 @@ private SelectStatement flatten(SelectStatement 
select, SelectStatement subselec
 }
 }
 }
-
+OffsetNode offset = select.getOffset();
+if (offset != null) {
+if (offsetRewrite == null) {
+offsetRewrite = offset;
+} else {
+Integer offsetValue = OffsetCompiler.compile(null, select);
+Integer offsetValueSubselect = 
OffsetCompiler.compile(null, subselect);
+if (offsetValue != null && offsetValueSubselect != null) {
+offsetRewrite = offsetValue < offsetValueSubselect ? 
offset : offsetRewrite;
+} else {
+return select;
+}
+}
+}
+
--- End diff --

Not sure if this would be correct. Suppose we have "select * from (select a 
from t offset 2 limit 8) offset 3", guess we should return the 5th row instead. 
If you consider the logic is too complicated to optimize at compiletime, you 
can simply quit flattening.


> support mysql "limit,offset" clauses 
> -
>
> Key: PHOENIX-2722
> URL: https://issues.apache.org/jira/browse/PHOENIX-2722
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Minor
> Attachments: PHOENIX-2722.patch, PHOENIX-2722_formatted.patch
>
>
> For serial query(query with “serial" hint or  “limit" without "order by”), we 
> can limit each scan(using page filter) to “limit+offset” instead of limit 
> earlier.
> And then, for all queries, we can forward the relevant client iterators to 
> the offset provided and then return the result.
> syntax
> {code}
> [ LIMIT { count } ]
> [ OFFSET start [ ROW | ROWS ] ]
> [ FETCH { FIRST | NEXT } [ count ] { ROW | ROWS } ONLY ]
> {code}
> Some new keywords(OFFSET,FETCH,ROW, ROWS,ONLY) are getting introduced so 
> users might need to see that they are not using them as column name or 
> something.
> WDYT, [~jamestaylor]



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

[GitHub] phoenix pull request: PHOENIX-2722 support mysql limit,offset clau...

[maryannxue]

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

https://github.com/apache/phoenix/pull/154#discussion_r57269271
  
--- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/compile/SubselectRewriter.java ---
@@ -202,14 +204,30 @@ private SelectStatement flatten(SelectStatement 
select, SelectStatement subselec
 }
 }
 }
-
+OffsetNode offset = select.getOffset();
+if (offset != null) {
+if (offsetRewrite == null) {
+offsetRewrite = offset;
+} else {
+Integer offsetValue = OffsetCompiler.compile(null, select);
+Integer offsetValueSubselect = 
OffsetCompiler.compile(null, subselect);
+if (offsetValue != null && offsetValueSubselect != null) {
+offsetRewrite = offsetValue < offsetValueSubselect ? 
offset : offsetRewrite;
+} else {
+return select;
+}
+}
+}
+
--- End diff --

Not sure if this would be correct. Suppose we have "select * from (select a 
from t offset 2 limit 8) offset 3", guess we should return the 5th row instead. 
If you consider the logic is too complicated to optimize at compiletime, you 
can simply quit flattening.


---
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-2794) Flatten nested aggregate queries when possible

[James Taylor (JIRA)]

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

James Taylor commented on PHOENIX-2794:
---

[~julianhyde] - does Calcite already do anything along these lines?

> Flatten nested aggregate queries when possible
> --
>
> Key: PHOENIX-2794
> URL: https://issues.apache.org/jira/browse/PHOENIX-2794
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>
> The following query:
> {code}
> SELECT TRUNC(ts,'HOUR'), AVG(avg_val)
> FROM (SELECT AVG(val),ts FROM T GROUP BY ts)
> GROUP BY TRUNC(ts,'HOUR');
> {code}
> will run much more efficiently if flattened so that the hourly bucketing is 
> done on the server-side like this:
> {code}
> SELECT TRUNC(ts,'HOUR'), AVG(val)
> FROM T
> GROUP BY TRUNC(ts,'HOUR');
> {code}
> We should flatten when possible. Not sure what the general rule is, but 
> perhaps if the inner and outer aggregate function matches, you can always do 
> this? Maybe only for some aggregate functions like SUM, MIN, MAX, AVG?
> This comes up in time series queries in particular.



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

[jira] [Updated] (PHOENIX-2794) Flatten nested aggregate queries when possible

[James Taylor (JIRA)]

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

James Taylor updated PHOENIX-2794:
--
Summary: Flatten nested aggregate queries when possible  (was: Optimize 
aggregates of aggregates when possible)

> Flatten nested aggregate queries when possible
> --
>
> Key: PHOENIX-2794
> URL: https://issues.apache.org/jira/browse/PHOENIX-2794
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>
> The following query:
> {code}
> SELECT TRUNC(ts,'HOUR'), AVG(avg_val)
> FROM (SELECT AVG(val),ts FROM T GROUP BY ts)
> GROUP BY TRUNC(ts,'HOUR');
> {code}
> will run much more efficiently if flattened so that the hourly bucketing is 
> done on the server-side like this:
> {code}
> SELECT TRUNC(ts,'HOUR'), AVG(val)
> FROM T
> GROUP BY TRUNC(ts,'HOUR');
> {code}
> We should flatten when possible. Not sure what the general rule is, but 
> perhaps if the inner and outer aggregate function matches, you can always do 
> this? Maybe only for some aggregate functions like SUM, MIN, MAX, AVG?
> This comes up in time series queries in particular.



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

[jira] [Created] (PHOENIX-2794) Optimize aggregates of aggregates when possible

[James Taylor (JIRA)]

James Taylor created PHOENIX-2794:
-

 Summary: Optimize aggregates of aggregates when possible
 Key: PHOENIX-2794
 URL: https://issues.apache.org/jira/browse/PHOENIX-2794
 Project: Phoenix
  Issue Type: Bug
Reporter: James Taylor


The following query:
{code}
SELECT TRUNC(ts,'HOUR'), AVG(avg_val)
FROM (SELECT AVG(val),ts FROM T GROUP BY ts)
GROUP BY TRUNC(ts,'HOUR');
{code}
will run much more efficiently if flattened so that the hourly bucketing is 
done on the server-side like this:
{code}
SELECT TRUNC(ts,'HOUR'), AVG(val)
FROM T
GROUP BY TRUNC(ts,'HOUR');
{code}
We should flatten when possible. Not sure what the general rule is, but perhaps 
if the inner and outer aggregate function matches, you can always do this? 
Maybe only for some aggregate functions like SUM, MIN, MAX, AVG?

This comes up in time series queries in particular.




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

[jira] [Created] (PHOENIX-2793) Date-time functions on null dates return no data

[Kevin Liew (JIRA)]

Kevin Liew created PHOENIX-2793:
---

 Summary: Date-time functions on null dates return no data
 Key: PHOENIX-2793
 URL: https://issues.apache.org/jira/browse/PHOENIX-2793
 Project: Phoenix
  Issue Type: Bug
Affects Versions: 4.4.0
 Environment: HDP 2.3.4
Reporter: Kevin Liew
Priority: Minor


{code:sql}select month(at1.DATE_col5) from at1 where date_col5 is null{code}
returns zero rows but should return one null row.



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

[jira] [Commented] (PHOENIX-2783) Creating secondary index with duplicated columns makes the catalog corrupted

[Biju Nair (JIRA)]

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

Biju Nair commented on PHOENIX-2783:


Thanks [~sergey.soldatov] for sharing the experiment results. Just to confirm, 
the {{listMultimapTest}} was simulating the nested {{for loop}} as in the 
patch. Correct? Agree about string concatenation but thought of the code being 
a bit more cleaner. 

> Creating secondary index with duplicated columns makes the catalog corrupted
> 
>
> Key: PHOENIX-2783
> URL: https://issues.apache.org/jira/browse/PHOENIX-2783
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.7.0
>Reporter: Sergey Soldatov
>Assignee: Sergey Soldatov
> Attachments: PHOENIX-2783-1.patch, PHOENIX-2783-2.patch
>
>
> Simple example
> {noformat}
> create table x (t1 varchar primary key, t2 varchar, t3 varchar);
> create index idx on x (t2) include (t1,t3,t3);
> {noformat}
> cause an exception that duplicated column was detected, but the client 
> updates the catalog before throwing it and makes it unusable. All following 
> attempt to use table x cause an exception ArrayIndexOutOfBounds. This problem 
> was discussed on the user list recently. 
> The cause of the problem is that check for duplicated columns happen in 
> PTableImpl after MetaDataClient complete the server createTable. 
> The simple way to fix is to add a similar check in MetaDataClient before 
> createTable is called. 
> Possible someone can suggest a more elegant way to fix it? 



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

[jira] [Commented] (PHOENIX-2751) Wrong filtering for VARCHAR with null

[Sergey Soldatov (JIRA)]

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

Sergey Soldatov commented on PHOENIX-2751:
--

Nick, could you please check whether this bug is still reproducible with 4.7?

> Wrong filtering for VARCHAR with null
> -
>
> Key: PHOENIX-2751
> URL: https://issues.apache.org/jira/browse/PHOENIX-2751
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.5.1
>Reporter: Nick Hryhoriev
>Priority: Critical
> Attachments: test_data.csv
>
>
> I ve got table 
> CREATE TABLE integration_tests.connector_test(
> cf1.date_full timestamp,
> cf1.date_empty timestamp,
> cf1.date_with_null timestamp,
> cf1.date_milliseconds bigint,
> cf1.date_milliseconds_empty bigint,
> cf1.date_milliseconds_with_null bigint,
> cf1.date_seconds bigint,
> cf1.date_seconds_empty bigint,
> cf1.date_seconds_with_null bigint,
> cf1.date_year bigint,
> cf2.date_year_with_null bigint,
> cf2.double_full DOUBLE,
> cf2.double_with_null DOUBLE,
> cf2.double_empty DOUBLE,
> cf2.integer_full bigint,
> cf3.integer_with_null bigint,
> cf3.integer_empty bigint,
> cf3.string_with_null varchar,
> cf3.string_empty varchar,
> cf3.string_full varchar,
> id bigint,
> CONSTRAINT pk PRIMARY KEY (id))
> SALT_BUCKETS=3,
> STORE_NULLS=true,
> DEFAULT_COLUMN_FAMILY='cf4',
> COMPRESSION='GZ'
> where in with_null column 30% null values.
> When i run 
> Select ds.double_full, ds.string_with_null from 
> integration_tests.connector_test ds  -> i ve got all my nulls. 
> When i run 
> Select ds.double_full, ds.string_with_null from 
> integration_tests.connector_test ds where ds.string_with_null is NULL-> ive 
> got empty result.
> is not NULL work well. and also i ve find issue in mail list that a really 
> close to this one 
> https://mail-archives.apache.org/mod_mbox/phoenix-user/201505.mbox/%3cd18383cd.7f6d%25a...@hortonworks.com%3E.



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

Re: Continuing Trace UI work?

[Jesse Yates]

I sent this to James the other day, didn't get a chance to post it on the
JIRA yet:

*I was poking around htrace and zipkin and it looks like zipkin has a jdbc
storage plugin. Might be a nice little piece of work to integrate phoenix
into that - would act as storage for the zipkin collector (rather than
cassandra/mysql) and query interface. It might be nice to just use zipkin's
UI with HTrace spans all the way and rip out our tracing server.*

On Wed, Mar 23, 2016 at 10:56 AM Ayola Jayamaha 
wrote:

> Hi All,
>
> I am drafting my GSOC 2016 proposal. As it is done I will share with you
> all.
> I went through all jiras regard "phoenix trace UI"  and I brainstorm them
> for proposal. I am going to handle main two task
>
> 1. Phoenix trace web app : Finalize and bring it where users can used
>
>- Fixing all jira on there
>- Some improvements
>- Standardize it to industrial (using Bower and Grunt)
>
> Last week I was looking some other Apache projects who do they handle JS,
> web app in java repos.
>
> 2.  Bring Zipkin into the Phoenix Trace
>
>- I try some genrated tracing on Zipkin
>- Zipkin Architecture is feasible to integrate for  phoenix
>   -  Same time need some code level changes and I will work on them
>   with support of Phoenix and Zipkin communities
>
> User can used any tracing app depending on their user case,
>
> you ideas are well come.
>
> On Wed, Mar 16, 2016 at 12:08 AM, Ayola Jayamaha 
> wrote:
>
>> That is great,
>> I knew some in Zipkin (A. Cole) as I demo phoenix trace app for them last
>> time. I can get some help from them for to understand Zipkin  if any need
>> for  Jira1119.
>>
>>
>>
>> On Tue, Mar 15, 2016 at 11:47 PM, James Taylor 
>> wrote:
>>
>>> Yes, definitely.
>>>
>>> On Tue, Mar 15, 2016 at 11:09 AM, Ayola Jayamaha >> > wrote:
>>>
 Hi James,

 Is [1] considered in GSoC 2016?

 [1] https://issues.apache.org/jira/browse/PHOENIX-1119



 On Sat, Mar 12, 2016 at 11:38 PM, Ayola Jayamaha <
 raphaelan...@gmail.com> wrote:

> Thanks James
>
>  I will go each of them.
>
> On Thu, Mar 10, 2016 at 11:39 PM, James Taylor  > wrote:
>
>> Sounds great. Take a look at PHOENIX-2701 [1] and its subtasks. To
>> see all outstanding tracing work, make a look at all JIRAs with a 
>> "tracing"
>> label [2].
>>
>> Thanks,
>> James
>>
>> [1] https://issues.apache.org/jira/browse/PHOENIX-2701
>> [2]
>> https://issues.apache.org/jira/browse/PHOENIX-2701?jql=project%20%3D%20PHOENIX%20AND%20resolution%20%3D%20Unresolved%20and%20labels%3D%22tracing%22
>>
>> On Thu, Mar 10, 2016 at 6:29 AM, Ayola Jayamaha <
>> raphaelan...@gmail.com> wrote:
>>
>>> Hi,
>>> I didn't plan to participate in GSoC again. But since the results
>>> are still pending and I am doing a research at the University I thought 
>>> of
>>> participating in GSoC again.
>>>
>>> If that's fine I can think few more things to improve tracing web
>>> app and create some jira. I can make a proposal for GSoC 2016 if it's
>>> alright. And I like to work with the community since I am familiar with
>>> them.
>>>
>>> Thanks.
>>>
>>> On Wed, Mar 9, 2016 at 1:05 PM, James Taylor >> > wrote:
>>>
 Sounds good - will you be participating in the GSoC program again
 this year?

 On Tue, Mar 8, 2016 at 6:46 AM, Ayola Jayamaha <
 raphaelan...@gmail.com> wrote:

> Hi James,
>
> Yes everything is fine. University results are still pending(it's
> normal in Sri Lanka :) ).
>
> I am interested in moving forward with tracing in Phoenix if it's
> fine.
> We can try to improve the tracing web app and get it release.
>
> Thanks,
> Nishani
>
> On Mon, Mar 7, 2016 at 1:59 AM, James Taylor <
> jamestay...@apache.org> wrote:
>
>> Hi Nishani,
>> How's everything going? GSoC is starting up again. Any interest
>> in moving the tracing work forward in Phoenix?
>> Regards,
>> James
>>
>> On Wed, Nov 11, 2015 at 11:54 PM, James Taylor <
>> jamestay...@apache.org> wrote:
>>
>>> Excellent! Any time frame in mind?
>>> Thanks,
>>> James
>>>
>>> On Wed, Nov 11, 2015 at 11:13 PM, Ayola Jayamaha <
>>> raphaelan...@gmail.com> wrote:
>>>
 Hi James,

 I am continuing with the trace UI work.

 Thanks.

 On Thu, Nov 12, 2015 at 12:13 PM, James Taylor <
 jamestay...@apache.org> wrote:

> Hi Nishani,
> 

Re: Would like to volunteer for 4.8 release

[James Taylor]

+1. Thanks, Rajeshbabu. Likely will be some perf improvements too that
Samarth, Thomas, and I are working on.

James

On Wednesday, March 23, 2016, rajeshb...@apache.org <
chrajeshbab...@gmail.com> wrote:

> Hi Team,
>
> There is lot of working going on mainly local indexing new implementation,
> namespace support, some work in tracing, stabilization of transactions as
> well some performance improvements like IndexTool improvements and so on. I
> think April 3rd or 4th week would be better time for 4.8 release. I would
> like to volunteer as RM for the release.
>
> What do you think?
>
>
> Thanks,
> Rajeshbabu.
>

Would like to volunteer for 4.8 release

[rajeshb...@apache.org]

Hi Team,

There is lot of working going on mainly local indexing new implementation,
namespace support, some work in tracing, stabilization of transactions as
well some performance improvements like IndexTool improvements and so on. I
think April 3rd or 4th week would be better time for 4.8 release. I would
like to volunteer as RM for the release.

What do you think?


Thanks,
Rajeshbabu.

[jira] [Comment Edited] (PHOENIX-2783) Creating secondary index with duplicated columns makes the catalog corrupted

[Sergey Soldatov (JIRA)]

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

Sergey Soldatov edited comment on PHOENIX-2783 at 3/23/16 6:43 PM:
---

Actually I was thinking about using HashSet, but I don't like string 
concatenation. And I did some simple benchmarking for 10 entries 
{noformat}
Benchmark Mode  Cnt Score Error  Units
MyBenchmark.hashSetTest   avgt   15  21776823.378 ± 3728502.403  ns/op
MyBenchmark.listMultimapTest  avgt   15  20121794.022 ± 2185643.518  ns/op
{noformat}
It seems that ListMultiMap is still better a bit.




was (Author: sergey.soldatov):
Actually I was thinking about using HashSet, but I don't like string 
concatenation. And I did some simple benchmarking for 10 entries 
Benchmark Mode  Cnt Score Error  Units
MyBenchmark.hashSetTest   avgt   15  21776823.378 ± 3728502.403  ns/op
MyBenchmark.listMultimapTest  avgt   15  20121794.022 ± 2185643.518  ns/op

It seems that ListMultiMap is still better a bit.



> Creating secondary index with duplicated columns makes the catalog corrupted
> 
>
> Key: PHOENIX-2783
> URL: https://issues.apache.org/jira/browse/PHOENIX-2783
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.7.0
>Reporter: Sergey Soldatov
>Assignee: Sergey Soldatov
> Attachments: PHOENIX-2783-1.patch, PHOENIX-2783-2.patch
>
>
> Simple example
> {noformat}
> create table x (t1 varchar primary key, t2 varchar, t3 varchar);
> create index idx on x (t2) include (t1,t3,t3);
> {noformat}
> cause an exception that duplicated column was detected, but the client 
> updates the catalog before throwing it and makes it unusable. All following 
> attempt to use table x cause an exception ArrayIndexOutOfBounds. This problem 
> was discussed on the user list recently. 
> The cause of the problem is that check for duplicated columns happen in 
> PTableImpl after MetaDataClient complete the server createTable. 
> The simple way to fix is to add a similar check in MetaDataClient before 
> createTable is called. 
> Possible someone can suggest a more elegant way to fix it? 



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

[jira] [Commented] (PHOENIX-2783) Creating secondary index with duplicated columns makes the catalog corrupted

[Sergey Soldatov (JIRA)]

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

Sergey Soldatov commented on PHOENIX-2783:
--

Actually I was thinking about using HashSet, but I don't like string 
concatenation. And I did some simple benchmarking for 10 entries 
Benchmark Mode  Cnt Score Error  Units
MyBenchmark.hashSetTest   avgt   15  21776823.378 ± 3728502.403  ns/op
MyBenchmark.listMultimapTest  avgt   15  20121794.022 ± 2185643.518  ns/op

It seems that ListMultiMap is still better a bit.



> Creating secondary index with duplicated columns makes the catalog corrupted
> 
>
> Key: PHOENIX-2783
> URL: https://issues.apache.org/jira/browse/PHOENIX-2783
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.7.0
>Reporter: Sergey Soldatov
>Assignee: Sergey Soldatov
> Attachments: PHOENIX-2783-1.patch, PHOENIX-2783-2.patch
>
>
> Simple example
> {noformat}
> create table x (t1 varchar primary key, t2 varchar, t3 varchar);
> create index idx on x (t2) include (t1,t3,t3);
> {noformat}
> cause an exception that duplicated column was detected, but the client 
> updates the catalog before throwing it and makes it unusable. All following 
> attempt to use table x cause an exception ArrayIndexOutOfBounds. This problem 
> was discussed on the user list recently. 
> The cause of the problem is that check for duplicated columns happen in 
> PTableImpl after MetaDataClient complete the server createTable. 
> The simple way to fix is to add a similar check in MetaDataClient before 
> createTable is called. 
> Possible someone can suggest a more elegant way to fix it? 



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

[jira] [Updated] (PHOENIX-2792) Enable Kerberos auth over SPNEGO for QueryServer

[Josh Elser (JIRA)]

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

Josh Elser updated PHOENIX-2792:

Summary: Enable Kerberos auth over SPNEGO for QueryServer  (was: Enable 
Kerberos auth over SPNEGO for QuerySErver)

> Enable Kerberos auth over SPNEGO for QueryServer
> 
>
> Key: PHOENIX-2792
> URL: https://issues.apache.org/jira/browse/PHOENIX-2792
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2792.patch
>
>
> I've been working on adding in Kerberos authentication for Avatica in 
> CALCITE-1159. As always, PQS is my guinea pig.
> Here's a tentative patch which works with what I have staged over in Calcite. 
> After we get a 1.8 release of Avatica, we can bring that into Phoenix and 
> apply the changes to use the new API to enable SPNEGO.



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

[jira] [Updated] (PHOENIX-2792) Enable Kerberos auth over SPNEGO for QuerySErver

[Josh Elser (JIRA)]

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

Josh Elser updated PHOENIX-2792:

Attachment: PHOENIX-2792.patch

Here's my test patch (won't build unless you get the avatica 1.8.0-SNAPSHOT 
built).

Big change is that there's a wrapper added to phoenix-server-client to make the 
use of {{sqlline-thin.py}} transparent when you've already primed a TGT in the 
cache (e.g. you ran {{kinit}} on the CLI). This required pulling in 
hadoop-common (which sucks because we just want {{Configuration}}), but this is 
a necessary evil I guess?

I'll swing back around to this when I get an Avatica release out with these 
changes (will be a few weeks, likely).

> Enable Kerberos auth over SPNEGO for QuerySErver
> 
>
> Key: PHOENIX-2792
> URL: https://issues.apache.org/jira/browse/PHOENIX-2792
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2792.patch
>
>
> I've been working on adding in Kerberos authentication for Avatica in 
> CALCITE-1159. As always, PQS is my guinea pig.
> Here's a tentative patch which works with what I have staged over in Calcite. 
> After we get a 1.8 release of Avatica, we can bring that into Phoenix and 
> apply the changes to use the new API to enable SPNEGO.



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

[jira] [Created] (PHOENIX-2792) Enable Kerberos auth over SPNEGO for QuerySErver

[Josh Elser (JIRA)]

Josh Elser created PHOENIX-2792:
---

 Summary: Enable Kerberos auth over SPNEGO for QuerySErver
 Key: PHOENIX-2792
 URL: https://issues.apache.org/jira/browse/PHOENIX-2792
 Project: Phoenix
  Issue Type: Improvement
Reporter: Josh Elser
Assignee: Josh Elser
 Fix For: 4.8.0


I've been working on adding in Kerberos authentication for Avatica in 
CALCITE-1159. As always, PQS is my guinea pig.

Here's a tentative patch which works with what I have staged over in Calcite. 
After we get a 1.8 release of Avatica, we can bring that into Phoenix and apply 
the changes to use the new API to enable SPNEGO.



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

[jira] [Commented] (PHOENIX-2783) Creating secondary index with duplicated columns makes the catalog corrupted

[Biju Nair (JIRA)]

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

Biju Nair commented on PHOENIX-2783:


Hi [~sergey.soldatov], will it make the code better if we use {{hash}} with 
{{familyName+columnName}} as the key with a dummy value of 0 so that the check 
for the duplicate for the column in the index definition statement can be a 
simple {{get}} and {{put}} if the key is not in the {{hash}}. Just a thought.

> Creating secondary index with duplicated columns makes the catalog corrupted
> 
>
> Key: PHOENIX-2783
> URL: https://issues.apache.org/jira/browse/PHOENIX-2783
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.7.0
>Reporter: Sergey Soldatov
>Assignee: Sergey Soldatov
> Attachments: PHOENIX-2783-1.patch, PHOENIX-2783-2.patch
>
>
> Simple example
> {noformat}
> create table x (t1 varchar primary key, t2 varchar, t3 varchar);
> create index idx on x (t2) include (t1,t3,t3);
> {noformat}
> cause an exception that duplicated column was detected, but the client 
> updates the catalog before throwing it and makes it unusable. All following 
> attempt to use table x cause an exception ArrayIndexOutOfBounds. This problem 
> was discussed on the user list recently. 
> The cause of the problem is that check for duplicated columns happen in 
> PTableImpl after MetaDataClient complete the server createTable. 
> The simple way to fix is to add a similar check in MetaDataClient before 
> createTable is called. 
> Possible someone can suggest a more elegant way to fix it? 



--
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=15208633#comment-15208633
 ] 

ASF GitHub Bot commented on PHOENIX-1311:
-

Github user JamesRTaylor commented on the pull request:

https://github.com/apache/phoenix/pull/153#issuecomment-200406903
  
I just wonder how that'll work, @ankitsinghal. If it works, I suppose it's 
ok, but it muddies things a bit as views are all supposed to be contained in 
the same physical table. Do we change the views physical table name property? 
Do you have test cases around this?


> 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 the pull request:

https://github.com/apache/phoenix/pull/153#issuecomment-200406903
  
I just wonder how that'll work, @ankitsinghal. If it works, I suppose it's 
ok, but it muddies things a bit as views are all supposed to be contained in 
the same physical table. Do we change the views physical table name property? 
Do you have test cases around this?


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

[jira] [Updated] (PHOENIX-2751) Wrong filtering for VARCHAR with null

[Nick Hryhoriev (JIRA)]

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

Nick Hryhoriev updated PHOENIX-2751:

Priority: Critical  (was: Major)

> Wrong filtering for VARCHAR with null
> -
>
> Key: PHOENIX-2751
> URL: https://issues.apache.org/jira/browse/PHOENIX-2751
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.5.1
>Reporter: Nick Hryhoriev
>Priority: Critical
> Attachments: test_data.csv
>
>
> I ve got table 
> CREATE TABLE integration_tests.connector_test(
> cf1.date_full timestamp,
> cf1.date_empty timestamp,
> cf1.date_with_null timestamp,
> cf1.date_milliseconds bigint,
> cf1.date_milliseconds_empty bigint,
> cf1.date_milliseconds_with_null bigint,
> cf1.date_seconds bigint,
> cf1.date_seconds_empty bigint,
> cf1.date_seconds_with_null bigint,
> cf1.date_year bigint,
> cf2.date_year_with_null bigint,
> cf2.double_full DOUBLE,
> cf2.double_with_null DOUBLE,
> cf2.double_empty DOUBLE,
> cf2.integer_full bigint,
> cf3.integer_with_null bigint,
> cf3.integer_empty bigint,
> cf3.string_with_null varchar,
> cf3.string_empty varchar,
> cf3.string_full varchar,
> id bigint,
> CONSTRAINT pk PRIMARY KEY (id))
> SALT_BUCKETS=3,
> STORE_NULLS=true,
> DEFAULT_COLUMN_FAMILY='cf4',
> COMPRESSION='GZ'
> where in with_null column 30% null values.
> When i run 
> Select ds.double_full, ds.string_with_null from 
> integration_tests.connector_test ds  -> i ve got all my nulls. 
> When i run 
> Select ds.double_full, ds.string_with_null from 
> integration_tests.connector_test ds where ds.string_with_null is NULL-> ive 
> got empty result.
> is not NULL work well. and also i ve find issue in mail list that a really 
> close to this one 
> https://mail-archives.apache.org/mod_mbox/phoenix-user/201505.mbox/%3cd18383cd.7f6d%25a...@hortonworks.com%3E.



--
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=15208121#comment-15208121
 ] 

ASF GitHub Bot commented on PHOENIX-1311:
-

Github user ankitsinghal commented on the pull request:

https://github.com/apache/phoenix/pull/153#issuecomment-200264320
  
Currently ,VIEW can be created in different schema name than it's base 
table name. are you recommending to use same schema?

I checked MySQL and postgres and they also allow creation of VIEW in 
different namespace/schema than its physical table. (may be it's because VIEW 
is logical and can be created on joined tables residing in different namespaces 
[though phoenix doesn't support join query in VIEW currently])

http://dev.mysql.com/doc/refman/5.7/en/create-view.html
http://www.postgresql.org/docs/9.2/static/sql-createview.html
"If a schema name is given (for example, CREATE VIEW myschema.myview ...) 
then the view is created in the specified schema. Otherwise it is created in 
the current schema"

What do you think about VIEW Indexes created with different schema as they 
all share a single physical table for storage and currently with above changes 
we are keeping a index table in same hbase namespace as of it's base/physical 
table.


> 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 the pull request:

https://github.com/apache/phoenix/pull/153#issuecomment-200264320
  
Currently ,VIEW can be created in different schema name than it's base 
table name. are you recommending to use same schema?

I checked MySQL and postgres and they also allow creation of VIEW in 
different namespace/schema than its physical table. (may be it's because VIEW 
is logical and can be created on joined tables residing in different namespaces 
[though phoenix doesn't support join query in VIEW currently])

http://dev.mysql.com/doc/refman/5.7/en/create-view.html
http://www.postgresql.org/docs/9.2/static/sql-createview.html
"If a schema name is given (for example, CREATE VIEW myschema.myview ...) 
then the view is created in the specified schema. Otherwise it is created in 
the current schema"

What do you think about VIEW Indexes created with different schema as they 
all share a single physical table for storage and currently with above changes 
we are keeping a index table in same hbase namespace as of it's base/physical 
table.


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