[ 
https://issues.apache.org/jira/browse/HIVE-9167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14253679#comment-14253679
 ] 

Brock Noland commented on HIVE-9167:
------------------------------------

bq. do we real need add the crypto command for the beeline? 

Sergio mentioned this to me offline and my understanding is that we would not 
have the crypto command to beeline. It'd only be enabled for tests and thus not 
be a public API.

bq.  What I am trying to do with the crypto commands is that we can create 
encryption zones for specific tables during our tests. Users will have tables 
with different encryption zones, and I'd like to test different queries that 
work with these tables.

If we can do this without exposing the command to the end user (i.e. only in 
tests), I think this is a good approach. My reasoning is:

# We need to test db level encryption in addition to each table being a 
different encryption zone.
# I feel like being able to create the ez's in the q-file is a little less 
error prone than creating the ez's in a separate location. It'd be very easy to 
mis-name the location of a table and thus not actually test with an encrypted 
location.





> Enhance encryption testing framework to allow create keys & zones inside .q 
> files
> ---------------------------------------------------------------------------------
>
>                 Key: HIVE-9167
>                 URL: https://issues.apache.org/jira/browse/HIVE-9167
>             Project: Hive
>          Issue Type: Sub-task
>            Reporter: Sergio Peña
>            Assignee: Sergio Peña
>
> The current implementation of the encryption testing framework on HIVE-8900 
> initializes a couple of encrypted databases to be used on .q test files. This 
> is useful in order to make tests small, but it does not test all details 
> found on the encryption implementation, such as: encrypted tables with 
> different encryption strength in the same database.
> We need to allow this kind of encryption as it is how it will be used in the 
> real world where a database will have a few encrypted tables (not all the DB).
> Also, we need to make this encryption framework flexible so that we can 
> create/delete keys & zones on demand when running the .q files. 



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

Reply via email to