[jira] [Created] (HIVE-21750) INSERT OVERWRITE with empty result set does not clear transactional table
Todd Lipcon created HIVE-21750:
--
Summary: INSERT OVERWRITE with empty result set does not clear
transactional table
Key: HIVE-21750
URL: https://issues.apache.org/jira/browse/HIVE-21750
Project: Hive
Issue Type: Bug
Components: Hive
Affects Versions: 4.0.0
Reporter: Todd Lipcon
The following query:
{code}
INSERT OVERWRITE TABLE t SELECT 1 WHERE FALSE
{code}
should serve to truncate a table by producing an empty base data directory. In
fact no new base directory is created, so the table is not cleared. (at least
with an insert_only table, I didn't test full-ACID)
This bug does not seem to happen with non-transactional tables.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HIVE-21688) SLF4J binding warning message printed when invoking beeline
Todd Lipcon created HIVE-21688:
--
Summary: SLF4J binding warning message printed when invoking
beeline
Key: HIVE-21688
URL: https://issues.apache.org/jira/browse/HIVE-21688
Project: Hive
Issue Type: Bug
Affects Versions: 4.0.0
Reporter: Todd Lipcon
When I run beeline (or any other hive tool), it outputs the following:
{code}
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/data/1/todd/impala/toolchain/cdp_components-1056671/apache-hive-3.1.0.6.0.99.0-147-bin/lib/log4j-slf4j-impl-2.10.0.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/data/1/todd/impala/toolchain/cdp_components-1056671/hadoop-3.1.1.6.0.99.0-147/share/hadoop/common/lib/slf4j-log4j12-1.7.25.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.apache.logging.slf4j.Log4jLoggerFactory]
{code}
It seems that Hive moved to log4j2 in HIVE-11304 and started bundling the
log4j2 slf4j binding in HIVE-13015. Hadoop is still on log4j 1, so the SLF4J
bindings are conflicting and producing these errors on stderr. This may confuse
users, and makes it hard to understand which log4j properties files are getting
used.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HIVE-21683) ProxyFileSystem breaks with Hadoop trunk
Todd Lipcon created HIVE-21683:
--
Summary: ProxyFileSystem breaks with Hadoop trunk
Key: HIVE-21683
URL: https://issues.apache.org/jira/browse/HIVE-21683
Project: Hive
Issue Type: Bug
Reporter: Todd Lipcon
Assignee: Todd Lipcon
When trying to run with a recent build of Hadoop which includes HADOOP-15229 I
ran into the following stack:
{code}
Caused by: java.lang.IllegalArgumentException: Wrong FS:
pfile:/src/hive/itests/qtest/target/warehouse/src/kv1.txt, expected: file:///
at org.apache.hadoop.fs.FileSystem.checkPath(FileSystem.java:793)
~[hadoop-common-3.1.1.6.0.99.0-135.jar:?]
at
org.apache.hadoop.fs.RawLocalFileSystem.pathToFile(RawLocalFileSystem.java:86)
~[hadoop-common-3.1.1.6.0.99.0-135.jar:?]
at
org.apache.hadoop.fs.RawLocalFileSystem.deprecatedGetFileStatus(RawLocalFileSystem.java:636)
~[hadoop-common-3.1.1.6.0.99.0-135.jar:?]
at
org.apache.hadoop.fs.RawLocalFileSystem.getFileLinkStatusInternal(RawLocalFileSystem.java:930)
~[hadoop-common-3.1.1.6.0.99.0-135.jar:?]
at
org.apache.hadoop.fs.RawLocalFileSystem.getFileStatus(RawLocalFileSystem.java:631)
~[hadoop-common-3.1.1.6.0.99.0-135.jar:?]
at
org.apache.hadoop.fs.FilterFileSystem.getFileStatus(FilterFileSystem.java:456)
~[hadoop-common-3.1.1.6.0.99.0-135.jar:?]
at
org.apache.hadoop.fs.ChecksumFileSystem$ChecksumFSInputChecker.(ChecksumFileSystem.java:153)
~[hadoop-common-3.1.1.6.0.99.0-135.jar:?]
at
org.apache.hadoop.fs.ChecksumFileSystem.open(ChecksumFileSystem.java:354)
~[hadoop-common-3.1.1.6.0.99.0-135.jar:?]
at
org.apache.hadoop.fs.ChecksumFileSystem.lambda$openFileWithOptions$0(ChecksumFileSystem.java:846)
~[hadoop-common-3.1.1.6.0.99.0-135.jar:?]
at org.apache.hadoop.util.LambdaUtils.eval(LambdaUtils.java:52)
~[hadoop-common-3.1.1.6.0.99.0-135.jar:?]
at
org.apache.hadoop.fs.ChecksumFileSystem.openFileWithOptions(ChecksumFileSystem.java:845)
~[hadoop-common-3.1.1.6.0.99.0-135.jar:?]
at
org.apache.hadoop.fs.FileSystem$FSDataInputStreamBuilder.build(FileSystem.java:4522)
~[hadoop-common-3.1.1.6.0.99.0-135.jar:?]
at
org.apache.hadoop.mapred.LineRecordReader.(LineRecordReader.java:115)
~[hadoop-mapreduce-client-core-3.1.1.6.0.99.0-135.jar:?]{code}
We need to add appropriate path-swizzling wrappers for the new APIs in
ProxyFileSystem23
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HIVE-21682) Concurrent queries in tez local mode fail
Todd Lipcon created HIVE-21682: -- Summary: Concurrent queries in tez local mode fail Key: HIVE-21682 URL: https://issues.apache.org/jira/browse/HIVE-21682 Project: Hive Issue Type: Bug Reporter: Todd Lipcon Assignee: Todd Lipcon As noted in TEZ-3420, Hive running with Tez local mode breaks if multiple queries are submitted concurrently. As I noted [there|https://issues.apache.org/jira/browse/TEZ-3420?focusedCommentId=16831937=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16831937] it seems part of the problem is Hive's use of static global state for IOContext in the case of Tez. Another issue is the use of a JVM-wide ObjectRegistry -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HIVE-21675) CREATE VIEW IF NOT EXISTS broken
Todd Lipcon created HIVE-21675: -- Summary: CREATE VIEW IF NOT EXISTS broken Key: HIVE-21675 URL: https://issues.apache.org/jira/browse/HIVE-21675 Project: Hive Issue Type: Bug Affects Versions: 3.1.1 Reporter: Todd Lipcon CREATE VIEW IF NOT EXISTS returns an error rather than "OK" if the view already exists. This is a regression from Hive 2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HIVE-21667) Bad error message when non-ACID files are put in an insert_only ACID table
Todd Lipcon created HIVE-21667: -- Summary: Bad error message when non-ACID files are put in an insert_only ACID table Key: HIVE-21667 URL: https://issues.apache.org/jira/browse/HIVE-21667 Project: Hive Issue Type: Bug Components: Transactions Affects Versions: 3.1.0 Reporter: Todd Lipcon I created an insert_only transactional table, and then dropped a text file into the table's directory from a non-transaction-aware client. When I next queried the table, I got the following error: Error: java.io.IOException: java.io.IOException: Not a file: hdfs://localhost:20500/test-warehouse/trans/delta_002_002_ (state=,code=0) It seems that Hive saw the non-ACID file and fell back to some kind of non-ACID reader path, but then got confused by the delta directory. This case should either fall back to gracefully reading the file, or give an error message like "Unexpected file not conforming to ACID layout: . Data must be loaded using into transactional tables LOAD DATA." or something. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HIVE-21666) Bad behavior with 'insert_only' property on non-transactional table
Todd Lipcon created HIVE-21666: -- Summary: Bad behavior with 'insert_only' property on non-transactional table Key: HIVE-21666 URL: https://issues.apache.org/jira/browse/HIVE-21666 Project: Hive Issue Type: Bug Components: Transactions Reporter: Todd Lipcon I created a table with 'transactional_properties'='insert_only' but didn't specify 'transactional'='TRUE'. I was able to insert into this table, but when I tried to query it, I got a NumberFormatException since it appears the insert path used a non-transactional layout while the read path expected one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HIVE-21649) Passing an non-existent jar in HIVE_AUX_JARS_PATH produces incorrect error message
Todd Lipcon created HIVE-21649:
--
Summary: Passing an non-existent jar in HIVE_AUX_JARS_PATH
produces incorrect error message
Key: HIVE-21649
URL: https://issues.apache.org/jira/browse/HIVE-21649
Project: Hive
Issue Type: Bug
Components: Tez
Reporter: Todd Lipcon
I had configured HS2 with HIVE_AUX_JARS_PATH pointing to a non-existent
postgres jar. This resulted in queries failing with the following error:
{code}
tez.DagUtils: Localizing resource because it does not exist:
file:/data/1/todd/impala/fe/target/dependency/postgresql-42.2.5.jar to dest:
hdfs://localhost:20500/tmp/hive/todd/_tez_session_dir/9de357d5-59bf-4faa-8973-5212a08bc41a-resources/postgresql-42.2.5.jar
tez.DagUtils: Looks like another thread or process is writing the same file
tez.DagUtils: Waiting for the file
hdfs://localhost:20500/tmp/hive/todd/_tez_session_dir/9de357d5-59bf-4faa-8973-5212a08bc41a-resources/postgresql-42.2.5.jar
(5 attempts, with 5000ms interval)
tez.DagUtils: Could not find the jar that was being uploaded
{code}
This incorrect logging sent me on a wild goose chase looking for concurrency
issues, HDFS issues, etc, before I realized that the jar in fact didn't exist
on the local FS. This is due to some sketchy code which presumes that any
IOException is due to a writing conflict.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HIVE-21571) SHOW COMPACTIONS shows column names as its first output row
Todd Lipcon created HIVE-21571: -- Summary: SHOW COMPACTIONS shows column names as its first output row Key: HIVE-21571 URL: https://issues.apache.org/jira/browse/HIVE-21571 Project: Hive Issue Type: Bug Reporter: Todd Lipcon SHOW COMPACTIONS yields a resultset with nice column names, and then the first row of data is a repetition of those column names. This is somewhat confusing and hard to read. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HIVE-21487) COMPLETED_COMPACTIONS table missing appropriate indexes
Todd Lipcon created HIVE-21487:
--
Summary: COMPLETED_COMPACTIONS table missing appropriate indexes
Key: HIVE-21487
URL: https://issues.apache.org/jira/browse/HIVE-21487
Project: Hive
Issue Type: Bug
Affects Versions: 3.1.1
Reporter: Todd Lipcon
Looking at a MySQL install where HMS is pointed on Hive 3.1, I see a constant
stream of queries of the form:
{code}
select CC_STATE from COMPLETED_COMPACTIONS where CC_DATABASE =
'tpcds_orc_exact_1000' and CC_TABLE = 'catalog_returns' and CC_PARTITION =
'cr_returned_date_sk=2452851' and CC_STATE != 'a' order by CC_ID desc;
{code}
but the COMPLETED_COMPACTIONS table has no index. In this case it's resulting
in a full table scan over 115k rows, which takes around 100ms.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HIVE-21443) Better usability for SHOW COMPACTIONS
Todd Lipcon created HIVE-21443: -- Summary: Better usability for SHOW COMPACTIONS Key: HIVE-21443 URL: https://issues.apache.org/jira/browse/HIVE-21443 Project: Hive Issue Type: Improvement Components: Transactions Reporter: Todd Lipcon Currently on a test cluster the output of 'SHOW COMPACTIONS' has 117k rows. This makes it basically useless to work with. For better usability, we should support syntax like 'SHOW COMPACTIONS IN ' or maybe 'SHOW COMPACTIONS ON ' (particular syntax to be chosen for consistency with other operations I suppose). Alternatively (or maybe in addition) it seems like it would be nice to expose the same data in a queryable table (eg in information_schema or a system namespace) so that I could do things like: SELECT dbname, state, count(*) from compactions group by 1,2; -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HIVE-19715) Consolidated and flexible API for fetching partition metadata from HMS
Todd Lipcon created HIVE-19715: -- Summary: Consolidated and flexible API for fetching partition metadata from HMS Key: HIVE-19715 URL: https://issues.apache.org/jira/browse/HIVE-19715 Project: Hive Issue Type: New Feature Components: Standalone Metastore Reporter: Todd Lipcon Currently, the HMS thrift API exposes 17 different APIs for fetching partition-related information. There is somewhat of a combinatorial explosion going on, where each API has variants with and without "auth" info, by pspecs vs names, by filters, by exprs, etc. Having all of these separate APIs long term is a maintenance burden and also more confusing for consumers. Additionally, even with all of these APIs, there is a lack of granularity in fetching only the information needed for a particular use case. For example, in some use cases it may be beneficial to only fetch the partition locations without wasting effort fetching statistics, etc. This JIRA proposes that we add a new "one API to rule them all" for fetching partition info. The request and response would be encapsulated in structs. Some desirable properties: - the request should be able to specify which pieces of information are required (eg location, properties, etc) - in the case of partition parameters, the request should be able to do either whitelisting or blacklisting (eg to exclude large incremental column stats HLL dumped in there by Impala) - the request should optionally specify auth info (to encompas the "with_auth" variants) - the request should be able to designate the set of partitions to access through one of several different methods (eg "all", list, expr, part_vals, etc) - the struct should be easily evolvable so that new pieces of info can be added - the response should be designed in such a way as to avoid transferring redundant information for common cases (eg simple "dictionary coding" of strings like parameter names, etc) - the API should support some form of pagination for tables with large partition counts -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HIVE-19685) OpenTracing support for HMS
Todd Lipcon created HIVE-19685: -- Summary: OpenTracing support for HMS Key: HIVE-19685 URL: https://issues.apache.org/jira/browse/HIVE-19685 Project: Hive Issue Type: New Feature Components: Metastore Reporter: Todd Lipcon When diagnosing performance of metastore operations it isn't always obvious why something took a long time. Using a tracing framework can provide an end-to-end view of an operation including time spent in dependent systems (eg filesystem operations, RDBMS queries, etc). This JIRA proposes to integrate OpenTracing, which is a vendor-neutral tracing API into the HMS server and client. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HIVE-19605) TAB_COL_STATS table has no index on db/table name
Todd Lipcon created HIVE-19605: -- Summary: TAB_COL_STATS table has no index on db/table name Key: HIVE-19605 URL: https://issues.apache.org/jira/browse/HIVE-19605 Project: Hive Issue Type: Bug Components: Metastore Reporter: Todd Lipcon The TAB_COL_STATS table is missing an index on (CAT_NAME, DB_NAME, TABLE_NAME). The getTableColumnStatistics call queries based on this tuple. This makes those queries take a significant amount of time in large metastores since they do a full table scan. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HIVE-2163) SquirrelSQL 3.2.1 doesn't work with Hive 0.7.0
[
https://issues.apache.org/jira/browse/HIVE-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13032846#comment-13032846
]
Todd Lipcon commented on HIVE-2163:
---
Any idea of the root cause of this? Is SquirrelSQL doing something funky with
the thread's context classloader by any chance?
SquirrelSQL 3.2.1 doesn't work with Hive 0.7.0
--
Key: HIVE-2163
URL: https://issues.apache.org/jira/browse/HIVE-2163
Project: Hive
Issue Type: Bug
Components: JDBC
Affects Versions: 0.7.0
Reporter: Carl Steinbach
I tried using SquirrelSQL 3.2.1 with Hive 0.7.0 following the directions
located here: http://wiki.apache.org/hadoop/Hive/HiveJDBCInterface
I registered the Hive JDBC driver with SquirrelSQL, and then get the
following exception when I try to connect to the Hive Server process:
{noformat}
java.lang.RuntimeException: org.apache.hadoop.hive.ql.metadata.HiveException:
java.lang.RuntimeException: java.io.IOException: failure to login
at
org.apache.hadoop.hive.ql.session.SessionState.start(SessionState.java:226)
at org.apache.hadoop.hive.jdbc.HiveConnection.init(HiveConnection.java:72)
at org.apache.hadoop.hive.jdbc.HiveDriver.connect(HiveDriver.java:110)
at
net.sourceforge.squirrel_sql.fw.sql.SQLDriverManager.getConnection(SQLDriverManager.java:133)
at
net.sourceforge.squirrel_sql.client.mainframe.action.OpenConnectionCommand.execute(OpenConnectionCommand.java:97)
at
net.sourceforge.squirrel_sql.client.mainframe.action.ConnectToAliasCommand$SheetHandler.run(ConnectToAliasCommand.java:281)
at
net.sourceforge.squirrel_sql.client.mainframe.action.ConnectToAliasCommand$SheetHandler.performOK(ConnectToAliasCommand.java:238)
at
net.sourceforge.squirrel_sql.client.gui.db.ConnectionInternalFrame.connect(ConnectionInternalFrame.java:311)
at
net.sourceforge.squirrel_sql.client.gui.db.ConnectionInternalFrame.access$300(ConnectionInternalFrame.java:56)
at
net.sourceforge.squirrel_sql.client.gui.db.ConnectionInternalFrame$MyOkClosePanelListener.okPressed(ConnectionInternalFrame.java:461)
at
net.sourceforge.squirrel_sql.client.gui.OkClosePanel.fireButtonPressed(OkClosePanel.java:148)
at
net.sourceforge.squirrel_sql.client.gui.OkClosePanel.access$100(OkClosePanel.java:33)
at
net.sourceforge.squirrel_sql.client.gui.OkClosePanel$1.actionPerformed(OkClosePanel.java:174)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2028)
at
javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2351)
at
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
at
javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:236)
at java.awt.Component.processMouseEvent(Component.java:6374)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3267)
at java.awt.Component.processEvent(Component.java:6139)
at java.awt.Container.processEvent(Container.java:2085)
at java.awt.Component.dispatchEventImpl(Component.java:4736)
at java.awt.Container.dispatchEventImpl(Container.java:2143)
at java.awt.Component.dispatchEvent(Component.java:4566)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4621)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4282)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4212)
at java.awt.Container.dispatchEventImpl(Container.java:2129)
at java.awt.Window.dispatchEventImpl(Window.java:2478)
at java.awt.Component.dispatchEvent(Component.java:4566)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:680)
at java.awt.EventQueue.access$000(EventQueue.java:86)
at java.awt.EventQueue$1.run(EventQueue.java:639)
at java.awt.EventQueue$1.run(EventQueue.java:637)
at java.security.AccessController.doPrivileged(Native Method)
at
java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at
java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:98)
at java.awt.EventQueue$2.run(EventQueue.java:653)
at java.awt.EventQueue$2.run(EventQueue.java:651)
at java.security.AccessController.doPrivileged(Native Method)
at
java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:650)
at net.sourceforge.squirrel_sql.client.Main$1.dispatchEvent(Main.java:93)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:296)
at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:201)
at
[jira] [Commented] (HIVE-2162) Upgrade dependencies to Hadoop 0.20.2 and 0.20.203.0
[ https://issues.apache.org/jira/browse/HIVE-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13032658#comment-13032658 ] Todd Lipcon commented on HIVE-2162: --- Are you suggesting that we no longer support 0.20.2? Or that the secure-Hadoop dependency be on 0.20.203? Upgrade dependencies to Hadoop 0.20.2 and 0.20.203.0 Key: HIVE-2162 URL: https://issues.apache.org/jira/browse/HIVE-2162 Project: Hive Issue Type: Improvement Reporter: Owen O'Malley Hadoop has released 0.20.203.0 and we should upgrade Hive's dependency to it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HIVE-2162) Upgrade dependencies to Hadoop 0.20.2 and 0.20.203.0
[ https://issues.apache.org/jira/browse/HIVE-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13032662#comment-13032662 ] Todd Lipcon commented on HIVE-2162: --- Gotcha. Makes sense. Upgrade dependencies to Hadoop 0.20.2 and 0.20.203.0 Key: HIVE-2162 URL: https://issues.apache.org/jira/browse/HIVE-2162 Project: Hive Issue Type: Improvement Reporter: Owen O'Malley Hadoop has released 0.20.203.0 and we should upgrade Hive's dependency to it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HIVE-2064) Make call to SecurityUtil.getServerPrincipal unambiguous
[
https://issues.apache.org/jira/browse/HIVE-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13008535#comment-13008535
]
Todd Lipcon commented on HIVE-2064:
---
This broke with HADOOP-7104.
Patch looks good to me.
Make call to SecurityUtil.getServerPrincipal unambiguous
Key: HIVE-2064
URL: https://issues.apache.org/jira/browse/HIVE-2064
Project: Hive
Issue Type: Bug
Components: Security
Affects Versions: 0.7.0
Reporter: Eli Collins
Assignee: Eli Collins
Priority: Blocker
Fix For: 0.7.0
Attachments: hive-2064-1.patch
HadoopThriftAuthBridge20S calls SecurityUtil.getServerPrincipal and passes
null for the 2nd arg. When building against the hadoop security branch this
is a compilation error as it matches the signatures of both
getServerPrincipal methods (one takes a String for the 2nd arg, one an
InetAddress). This call needs to be made unambiguous eg by passing 0.0.0.0
instead of null, which per the getServerPrincipal javadoc is equivalent:
{quote}
It replaces hostname pattern with hostname, which should be
* fully-qualified domain name. If hostname is null or 0.0.0.0, it uses
* dynamically looked-up fqdn of the current host instead.
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (HIVE-1762) Multi-character delimiter strings do not work correctly
Multi-character delimiter strings do not work correctly
---
Key: HIVE-1762
URL: https://issues.apache.org/jira/browse/HIVE-1762
Project: Hive
Issue Type: Bug
Components: Serializers/Deserializers
Affects Versions: 0.5.0
Reporter: Todd Lipcon
I was trying to give a demo using the movielens data set, which uses '::' as a
delimiter (multiple characters). Using FIELDS TERMINATED BY '::' did not give
an error, but it seems to just split on ':' rather than '::'.
{code}
hive create table ml_ratings (userid int, movieid int, rating int, unixtime
string) row format delimited fields terminated by '::' stored as textfile;
...
hive select * from ml_ratings limit 5;
OK
1 NULL122
1 NULL185
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HIVE-842) Authentication Infrastructure for Hive
[ https://issues.apache.org/jira/browse/HIVE-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12924034#action_12924034 ] Todd Lipcon commented on HIVE-842: -- Hey Pradeep. Those changes seem reasonable. I'm not personally a fan of the login user concept in Hadoop security - it's static state, which prevents servers which may want to use multiple principals from doing so easily (eg if running a hive server with an embedded metastore, you may need a different principal for the two different pieces). But given that there is no renewer thread for non-loginuser keytab logins, it may be the only choice for now. Authentication Infrastructure for Hive -- Key: HIVE-842 URL: https://issues.apache.org/jira/browse/HIVE-842 Project: Hive Issue Type: New Feature Components: Server Infrastructure Reporter: Edward Capriolo Assignee: Todd Lipcon Attachments: hive-842.txt, HiveSecurityThoughts.pdf This issue deals with the authentication (user name,password) infrastructure. Not the authorization components that specify what a user should be able to do. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (HIVE-1526) Hive should depend on a release version of Thrift
[ https://issues.apache.org/jira/browse/HIVE-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12924036#action_12924036 ] Todd Lipcon commented on HIVE-1526: --- Hey John. I'm actually headed to Tokyo for the next two weeks so won't be at the contributors meeting. Perhaps Carl can look at this with you. Note that we should update the change to Thrift 0.5.0 release before committing, but the review can happen on current code. Hive should depend on a release version of Thrift - Key: HIVE-1526 URL: https://issues.apache.org/jira/browse/HIVE-1526 Project: Hive Issue Type: Task Components: Build Infrastructure, Clients Reporter: Carl Steinbach Assignee: Todd Lipcon Fix For: 0.7.0 Attachments: HIVE-1526.2.patch.txt, hive-1526.txt, libfb303.jar, libthrift.jar Hive should depend on a release version of Thrift, and ideally it should use Ivy to resolve this dependency. The Thrift folks are working on adding Thrift artifacts to a maven repository here: https://issues.apache.org/jira/browse/THRIFT-363 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
