[jira] [Created] (CALCITE-1036) DiffRepository should not insert new resources at the end of the repository

[Julian Hyde (JIRA)]

Julian Hyde created CALCITE-1036:


 Summary: DiffRepository should not insert new resources at the end 
of the repository
 Key: CALCITE-1036
 URL: https://issues.apache.org/jira/browse/CALCITE-1036
 Project: Calcite
  Issue Type: Bug
Reporter: Julian Hyde
Assignee: Julian Hyde


DiffRepository should not insert new resources at the end of the repository. 
When merging a patch, it makes it extremely likely that resources added by two 
development branches will conflict.

DiffRepository should instead add resources somewhere in the middle at a 
deterministic place. If the repository is sorted, it should merge into 
alphabetical order by test case name. If it is not sorted, or only somewhat 
sorted, it should place the new resource into approximately the right position: 
resource "aardvark" will go towards the start, and resource "zebra" will go 
near the end.



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

[jira] [Updated] (CALCITE-1025) Add support for HTTP Basic auth (for proxies) in Avatica HTTP Client

[Josh Elser (JIRA)]

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

Josh Elser updated CALCITE-1025:

Assignee: Phillip Rhodes  (was: Julian Hyde)

> Add support for HTTP Basic auth (for proxies) in Avatica HTTP Client
> 
>
> Key: CALCITE-1025
> URL: https://issues.apache.org/jira/browse/CALCITE-1025
> Project: Calcite
>  Issue Type: Improvement
>  Components: avatica
>Reporter: Phillip Rhodes
>Assignee: Phillip Rhodes
> Attachments: AvaticaConnection.patch, Driver.patch, 
> RemoteService.patch, http_auth_patch.patch, patch_against_1.2.0.patch
>
>
> Avatica serves as the base for the Phoenix "thin" JDBC driver, and supports a 
> JSON over HTTP protocol.  Being that it is HTTP, it would be desirable to 
> support standard HTTP mechanisms like HTTP BASIC authentication, which is 
> required by some proxy servers (for example, Knox).
> In particular, I've been working on deploying Phoenix behind Knox with Knox 
> mediating JDBC access using the "thin" driver based on Avatica.  In order to 
> make this work, I had to make a small change to Avatica in order to take the 
> supplied credentials and construct an Authorization header, and add it to the 
> HTTP request.  
> I have made this change and verified that it works, and would like to propose 
> merging it into the Avatica source.   I have two versions, one made against 
> HEAD and another which is a backport to an older version of Avatica (turns 
> out this was needed for the specific environment we were deploying in).
> It is a fairly small change, totaling about 10-15 lines of code, and - as far 
> as I can tell - should be totally non-invasive to existing users of Avatica.  
>  Basically I just add the HTTP Authorization header IF a username/password 
> combo is present, and do nothing otherwise.  If it is desired, we could also 
> wrap this code in a parameter based on a query string parameter or something. 
>  Maybe "enableProxyAuth=true" or something along those lines.
> I'll attach the actual modified code shortly, but in the meantime wanted to 
> start a discussion around this proposed change.  I have run this by some 
> people inside HortonWorks and they are in favor of implementing this so that 
> it can become part of HDP.   Being able to use Knox (or, in theory, any other 
> proxy server) to mediate JDBC access to Phoenix seems to be a desirable 
> thing.  Thoughts?  



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