[jira] [Commented] (HIVE-2504) Warehouse table subdirectories should inherit the group permissions of the warehouse parent directory
[
https://issues.apache.org/jira/browse/HIVE-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249581#comment-13249581
]
Ashutosh Chauhan commented on HIVE-2504:
I agree that fiddling with umask is not the cleanest approach here. But, I am
not sure about *always* inheriting permissions either, since this effectively
implies the whole sub-tree of warehouse dir will have same permissions as
warehouse dir itself. Concretely, lets consider following example. Lets say, wh
dir has 700 perms. Then, if I create table (which only owner of wh can do) I
will end up with either 775 or 755 (depending on whether it was before or after
the earlier patch of jira). However, with your patch, table dir will end up
with 700. In the earlier case, anyone could have read the tables, but now with
your approach only owner can read. Now, which of this is correct behavior is
open for debate and depends on which security model you have as your premise.
Additionally, this will be change of behavior then the current behavior. So, I
suggest you define a new config variable like {{hive.warehouse.inherit.perms}}
or something similar and set it to false by default. And then take your code
path of inheriting parent perms in case it is set to true. Thoughts?
Warehouse table subdirectories should inherit the group permissions of the
warehouse parent directory
-
Key: HIVE-2504
URL: https://issues.apache.org/jira/browse/HIVE-2504
Project: Hive
Issue Type: Bug
Components: Metastore
Reporter: Carl Steinbach
Assignee: Rohini Palaniswamy
Fix For: 0.9.0
Attachments: HIVE-2504.patch, HIVE-2504.patch
When the Hive Metastore creates a subdirectory in the Hive warehouse for
a new table it does so with the default HDFS permissions. Since the default
dfs.umask value is 022, this means that the new subdirectory will not inherit
the
group write permissions of the hive warehouse directory.
We should make the umask used by Warehouse.mkdirs() configurable, and set
it to use a default value of 002.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HIVE-2767) Optionally use framed transport with metastore
[
https://issues.apache.org/jira/browse/HIVE-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249582#comment-13249582
]
Ashutosh Chauhan commented on HIVE-2767:
After your patch test {{ant test -Dtestcase=TestHiveServerSessions}} is timing
out. Can you take a look?
Optionally use framed transport with metastore
--
Key: HIVE-2767
URL: https://issues.apache.org/jira/browse/HIVE-2767
Project: Hive
Issue Type: New Feature
Components: Metastore
Reporter: Travis Crawford
Assignee: Travis Crawford
Attachments: HIVE-2767.D2661.1.patch, HIVE-2767.D2661.2.patch,
HIVE-2767.D2661.3.patch, HIVE-2767.patch.txt, HIVE-2767_a.patch.txt
Users may want/need to use thrift's framed transport when communicating with
the Hive MetaStore. This patch adds a new property
{{hive.metastore.thrift.framed.transport.enabled}} that enables the framed
transport (defaults to off, aka no change from before the patch). This
property must be set for both clients and the HMS server.
It wasn't immediately clear how to use the framed transport with SASL, so as
written an exception is thrown if you try starting the server with both
options. If SASL and the framed transport will indeed work together I can
update the patch (although I don't have a secured environment to test in).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Make hive support various charsets
Hi I have created an issue HIVE-2917 and submitted patch through Phabricator. Is there anyone who would like to review it? Thanks, Kai Zhang 2012/3/29 Namit Jain nj...@fb.com Kai, That would be great. Please file a jura, and submit a patch. We would definitely like to get it for the whole community Thanks, -namit On 3/28/12 8:46 PM, Zhang Kai zhangk1...@gmail.com wrote: Hi all I've been working with hive for some time. In my company, we use hive for querying on large datasets and found it's very easy to use. However we also found hive is lack of various charsets support so that we have to manually transform data files to utf-8 encoding before loading them into hive. So I have made a patch to make hive supports setting charset when creating a table. And the charset property will be used by SerDe when it serialize or deserialize data. The modified hql is like: CREATE TABLE tbl1 (col1 STRING) ROW FORMAT CHARET GBK DELIMITED FIELDS TERMINATED BY '\t'; I'm very happy to contribute this to the community and looking forward to your feedbacks. Thanks, Kai Zhang
Re: HiveServer2 Thrift API Proposal
This is a very good news . 于 2012年04月08日 10:58, Carl Steinbach 写道: Hi, I wrote up a proposal for a new HiveServer2 Thrift API. It's available on the wiki here: https://cwiki.apache.org/confluence/display/Hive/HiveServer2+Thrift+API I'd appreciate it greatly if all interested parties would review the proposal and respond with feedback. We can discuss any remaining issues at the next Hive Contributors Meeting on April 18th. Thanks. Carl
[jira] [Created] (HIVE-2933) analyze command throw NPE when table doesn't exists
analyze command throw NPE when table doesn't exists --- Key: HIVE-2933 URL: https://issues.apache.org/jira/browse/HIVE-2933 Project: Hive Issue Type: Bug Components: Statistics Affects Versions: 0.8.1 Reporter: alex gemini Priority: Minor analyze command throw NPE when table doesn't exists -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HIVE-2934) desc command didn't print correct compression status
desc command didn't print correct compression status Key: HIVE-2934 URL: https://issues.apache.org/jira/browse/HIVE-2934 Project: Hive Issue Type: Bug Components: CLI Affects Versions: 0.8.1 Reporter: alex gemini Priority: Minor desc command always print compression status NO , test with lzo compression. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HIVE-1721) use bloom filters to improve the performance of joins
[ https://issues.apache.org/jira/browse/HIVE-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13249650#comment-13249650 ] alex gemini commented on HIVE-1721: --- the description said in case of map-join , so this jira create before map side join implementation? use bloom filters to improve the performance of joins - Key: HIVE-1721 URL: https://issues.apache.org/jira/browse/HIVE-1721 Project: Hive Issue Type: New Feature Components: Query Processor Reporter: Namit Jain Labels: gsoc, gsoc2012, optimization In case of map-joins, it is likely that the big table will not find many matching rows from the small table. Currently, we perform a hash-map lookup for every row in the big table, which can be pretty expensive. It might be useful to try out a bloom-filter containing all the elements in the small table. Each element from the big table is first searched in the bloom filter, and only in case of a positive match, the small table hash table is explored. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
