[jira] [Assigned] (HIVE-3338) Archives broken for hadoop 1.0

[Ashutosh Chauhan (JIRA)]

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

Ashutosh Chauhan reassigned HIVE-3338:
--

Assignee: Vikram Dixit K

> Archives broken for hadoop 1.0
> --
>
> Key: HIVE-3338
> URL: https://issues.apache.org/jira/browse/HIVE-3338
> Project: Hive
>  Issue Type: Bug
>  Components: Shims
>Affects Versions: 0.9.0
>Reporter: Vikram Dixit K
>Assignee: Vikram Dixit K
> Attachments: HIVE-3338.patch, HIVE-3338_2.patch, HIVE-3338_3.patch, 
> HIVE-3338_4.patch
>
>
> Hadoop archiving through hive is broken for 1.0. The hadoop archive command 
> line and paths have changed for 1.0 and were not addressed in the shim layer.

--
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-3338) Archives broken for hadoop 1.0

[Ashutosh Chauhan (JIRA)]

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

Ashutosh Chauhan commented on HIVE-3338:


@Vikram,
Can you create either a phabricator or review board entry of your patch ?

> Archives broken for hadoop 1.0
> --
>
> Key: HIVE-3338
> URL: https://issues.apache.org/jira/browse/HIVE-3338
> Project: Hive
>  Issue Type: Bug
>  Components: Shims
>Affects Versions: 0.9.0
>Reporter: Vikram Dixit K
> Attachments: HIVE-3338.patch, HIVE-3338_2.patch, HIVE-3338_3.patch, 
> HIVE-3338_4.patch
>
>
> Hadoop archiving through hive is broken for 1.0. The hadoop archive command 
> line and paths have changed for 1.0 and were not addressed in the shim layer.

--
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] [Updated] (HIVE-3338) Archives broken for hadoop 1.0

[Vikram Dixit K (JIRA)]

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

Vikram Dixit K updated HIVE-3338:
-

Attachment: HIVE-3338_4.patch

build file change reverted.

> Archives broken for hadoop 1.0
> --
>
> Key: HIVE-3338
> URL: https://issues.apache.org/jira/browse/HIVE-3338
> Project: Hive
>  Issue Type: Bug
>  Components: Shims
>Affects Versions: 0.9.0
>Reporter: Vikram Dixit K
> Attachments: HIVE-3338.patch, HIVE-3338_2.patch, HIVE-3338_3.patch, 
> HIVE-3338_4.patch
>
>
> Hadoop archiving through hive is broken for 1.0. The hadoop archive command 
> line and paths have changed for 1.0 and were not addressed in the shim layer.

--
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-3068) Add ability to export table metadata as JSON on table drop

[Andrew Chalfant (JIRA)]

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

Andrew Chalfant commented on HIVE-3068:
---

ping

> Add ability to export table metadata as JSON on table drop
> --
>
> Key: HIVE-3068
> URL: https://issues.apache.org/jira/browse/HIVE-3068
> Project: Hive
>  Issue Type: New Feature
>  Components: Metastore, Serializers/Deserializers
>Reporter: Andrew Chalfant
>Assignee: Andrew Chalfant
>Priority: Minor
>  Labels: features, newbie
> Attachments: HIVE-3068.2.patch.txt
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> When a table is dropped, the contents go to the users trash but the metadata 
> is lost. It would be super neat to be able to save the metadata as well so 
> that tables could be trivially re-instantiated via thrift.

--
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] [Updated] (HIVE-3338) Archives broken for hadoop 1.0

[Vikram Dixit K (JIRA)]

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

Vikram Dixit K updated HIVE-3338:
-

Attachment: HIVE-3338_3.patch

Missed the .out file for the new test.

> Archives broken for hadoop 1.0
> --
>
> Key: HIVE-3338
> URL: https://issues.apache.org/jira/browse/HIVE-3338
> Project: Hive
>  Issue Type: Bug
>  Components: Shims
>Affects Versions: 0.9.0
>Reporter: Vikram Dixit K
> Attachments: HIVE-3338.patch, HIVE-3338_2.patch, HIVE-3338_3.patch
>
>
> Hadoop archiving through hive is broken for 1.0. The hadoop archive command 
> line and paths have changed for 1.0 and were not addressed in the shim layer.

--
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: Review Request: This function overloads the current DateDiff(expr1, expr2) by adding another parameter to specify the units.

[Carl Steinbach]

> On Aug. 10, 2012, midnight, Carl Steinbach wrote:
> > bq. SQL also has a DateDiff() function with some more acceptable units. The 
> > order of parameters is different between SQL and Hive. The reason for this 
> > is that Hive already has a DateDiff() function with the same first two 
> > parameters, and having this order here allows for that consistency within 
> > Hive.
> > 
> > It's possible for Hive to support the same input parameter order as 
> > SQLServer and Firebird without breaking backward compatibility. If there 
> > are two input parameters then it assumes both parameters are date strings. 
> > If there are three input parameters it assumes that the first parameter is 
> > the datepart and that the second and third parameters are the date strings.
> > 
> > Also, this patch treats the datepart as a string, but most implementations 
> > seem to recognize it as a bareword or token. I think the latter approach is 
> > probably better since it forces the datepart to be a constant which makes 
> > it possible to generate better optimized code.
> >

SQL Server Datediff docs: 
http://msdn.microsoft.com/en-us/library/aa258269(v=sql.80).aspx
Firebird SQL: 
http://www.firebirdsql.org/refdocs/langrefupd21-intfunc-datediff.html


- Carl


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/6027/#review10098
---


On July 18, 2012, 12:56 a.m., Shefali Vohra wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/6027/
> ---
> 
> (Updated July 18, 2012, 12:56 a.m.)
> 
> 
> Review request for hive and Ashutosh Chauhan.
> 
> 
> Description
> ---
> 
> Parameters
>  This function overloads the current DateDiff(expr1, expr2) by adding another 
> parameter to specify the units. It takes 3 parameters. The first two are 
> timestamps, and the formats accepted are:
>  -MM-dd
>  -MM-dd HH:mm:ss
>  -MM-dd HH:mm:ss.milli
> 
> These are the formats accepted by the current DateDiff(expr1, expr2) function 
> and allow for that consistency. The accepted data types for the timestamp 
> will be Text, TimestampWritable, Date, and String, just as with the already 
> existing function.
> 
> The third parameter is the units the user wants the response to be in. 
> Acceptable units are:
>  Microsecond
>  Millisecond
>  Second
>  Minute
>  Hour
>  Day
>  Week
>  Month
>  Quarter
>  Year
> 
> When calculating the difference, the full timestamp is used when the 
> specified unit is hour or smaller (microsecond, millisecond, second, minute, 
> hour), and only the date part is used if the unit is day or larger (day, 
> week, month, quarter, year). If for the smaller units the time is not 
> specified and the format -MM-dd is used, the time 00:00:00.0 is used. 
> Leap years are accounted for by the Calendar class in Java, which inherently 
> addresses the issue.
> 
> The assumption is made that all these time parameters are in the same time 
> zone.
> 
> Return Value
>  The function returns expr1 - expr2 expressed as an int in the units 
> specified.
> 
> Hive vs. SQL
>  SQL also has a DateDiff() function with some more acceptable units. The 
> order of parameters is different between SQL and Hive. The reason for this is 
> that Hive already has a DateDiff() function with the same first two 
> parameters, and having this order here allows for that consistency within 
> Hive.
> 
> Example Query
>  hive > DATEDIFF(DATE_FIELD, '2012-06-01', ‘day’); 
> 
> Diagnostic Error Messages
>  Invalid table alias or column name reference
>  Table not found
> 
> 
> This addresses bug HIVE-3216.
> https://issues.apache.org/jira/browse/HIVE-3216
> 
> 
> Diffs
> -
> 
>   trunk/data/files/datetable.txt PRE-CREATION 
>   trunk/data/files/timestamptable.txt PRE-CREATION 
>   trunk/ql/src/java/org/apache/hadoop/hive/ql/udf/UDFDateDiff.java 1362724 
>   trunk/ql/src/test/queries/clientnegative/udf_datediff.q PRE-CREATION 
>   trunk/ql/src/test/queries/clientpositive/udf_datediff.q 1362724 
>   trunk/ql/src/test/results/clientnegative/udf_datediff.q.out PRE-CREATION 
>   trunk/ql/src/test/results/clientpositive/udf_datediff.q.out 1362724 
> 
> Diff: https://reviews.apache.org/r/6027/diff/
> 
> 
> Testing
> ---
> 
> positive and negative test cases included
> 
> 
> Thanks,
> 
> Shefali Vohra
> 
>

Re: Review Request: This function overloads the current DateDiff(expr1, expr2) by adding another parameter to specify the units.

[Carl Steinbach]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/6027/#review10098
---


bq. SQL also has a DateDiff() function with some more acceptable units. The 
order of parameters is different between SQL and Hive. The reason for this is 
that Hive already has a DateDiff() function with the same first two parameters, 
and having this order here allows for that consistency within Hive.

It's possible for Hive to support the same input parameter order as SQLServer 
and Firebird without breaking backward compatibility. If there are two input 
parameters then it assumes both parameters are date strings. If there are three 
input parameters it assumes that the first parameter is the datepart and that 
the second and third parameters are the date strings.

Also, this patch treats the datepart as a string, but most implementations seem 
to recognize it as a bareword or token. I think the latter approach is probably 
better since it forces the datepart to be a constant which makes it possible to 
generate better optimized code.


- Carl Steinbach


On July 18, 2012, 12:56 a.m., Shefali Vohra wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/6027/
> ---
> 
> (Updated July 18, 2012, 12:56 a.m.)
> 
> 
> Review request for hive and Ashutosh Chauhan.
> 
> 
> Description
> ---
> 
> Parameters
>  This function overloads the current DateDiff(expr1, expr2) by adding another 
> parameter to specify the units. It takes 3 parameters. The first two are 
> timestamps, and the formats accepted are:
>  -MM-dd
>  -MM-dd HH:mm:ss
>  -MM-dd HH:mm:ss.milli
> 
> These are the formats accepted by the current DateDiff(expr1, expr2) function 
> and allow for that consistency. The accepted data types for the timestamp 
> will be Text, TimestampWritable, Date, and String, just as with the already 
> existing function.
> 
> The third parameter is the units the user wants the response to be in. 
> Acceptable units are:
>  Microsecond
>  Millisecond
>  Second
>  Minute
>  Hour
>  Day
>  Week
>  Month
>  Quarter
>  Year
> 
> When calculating the difference, the full timestamp is used when the 
> specified unit is hour or smaller (microsecond, millisecond, second, minute, 
> hour), and only the date part is used if the unit is day or larger (day, 
> week, month, quarter, year). If for the smaller units the time is not 
> specified and the format -MM-dd is used, the time 00:00:00.0 is used. 
> Leap years are accounted for by the Calendar class in Java, which inherently 
> addresses the issue.
> 
> The assumption is made that all these time parameters are in the same time 
> zone.
> 
> Return Value
>  The function returns expr1 - expr2 expressed as an int in the units 
> specified.
> 
> Hive vs. SQL
>  SQL also has a DateDiff() function with some more acceptable units. The 
> order of parameters is different between SQL and Hive. The reason for this is 
> that Hive already has a DateDiff() function with the same first two 
> parameters, and having this order here allows for that consistency within 
> Hive.
> 
> Example Query
>  hive > DATEDIFF(DATE_FIELD, '2012-06-01', ‘day’); 
> 
> Diagnostic Error Messages
>  Invalid table alias or column name reference
>  Table not found
> 
> 
> This addresses bug HIVE-3216.
> https://issues.apache.org/jira/browse/HIVE-3216
> 
> 
> Diffs
> -
> 
>   trunk/data/files/datetable.txt PRE-CREATION 
>   trunk/data/files/timestamptable.txt PRE-CREATION 
>   trunk/ql/src/java/org/apache/hadoop/hive/ql/udf/UDFDateDiff.java 1362724 
>   trunk/ql/src/test/queries/clientnegative/udf_datediff.q PRE-CREATION 
>   trunk/ql/src/test/queries/clientpositive/udf_datediff.q 1362724 
>   trunk/ql/src/test/results/clientnegative/udf_datediff.q.out PRE-CREATION 
>   trunk/ql/src/test/results/clientpositive/udf_datediff.q.out 1362724 
> 
> Diff: https://reviews.apache.org/r/6027/diff/
> 
> 
> Testing
> ---
> 
> positive and negative test cases included
> 
> 
> Thanks,
> 
> Shefali Vohra
> 
>

Atlassian JIRA Issue.

[Gang Tim Liu]

Dear all,

Have you seen problem while creating jira issue today?

I tried to create jira issue and it showed exception in window but
actually issue is created. The created issues are abnormal: it missed
actions like "submit patch".

It also doesn't allow me to close/resolve them.

So, you will see a few of them for the same issue:

HIVE-3372 
 HIVE-3371 
 HIVE-3370 
 HIVE-3369 



Thanks

Tim

On 8/9/12 4:09 PM, "Gang Tim Liu (JIRA)"  wrote:

>
> [ 
>https://issues.apache.org/jira/browse/HIVE-3371?page=com.atlassian.jira.pl
>ugin.system.issuetabpanels:worklog-tabpanel\#worklog-{worklog.getId()} ]
>
>Gang Tim Liu logged work on HIVE-3371:
>--
>
>Author: Gang Tim Liu
>Created on: 09/Aug/12 23:08
>Start Date: 09/Aug/12 23:08
>Worklog Time Spent: 48h
>
>Issue Time Tracking
>---
>
>Worklog Id: (was: 13834)
>Time Spent: 48h
>Remaining Estimate: 0h
>
>> Local mode errors point to the wrong file
>> -
>>
>> Key: HIVE-3371
>> URL: https://issues.apache.org/jira/browse/HIVE-3371
>> Project: Hive
>>  Issue Type: Bug
>>  Components: CLI
>>Reporter: Gang Tim Liu
>>Assignee: Gang Tim Liu
>>Priority: Minor
>> Attachments: hive-3371
>>
>>  Time Spent: 48h
>>  Remaining Estimate: 0h
>>
>>  This is a classic example of a query that fails due to a bad udf in
>>local mode:
>> Ended Job = job_local_0001 with errors
>> Error during job, obtaining debugging information...
>> Execution failed with exit status: 2
>> Obtaining error information
>> Task failed!
>> Task ID:
>>   Stage-1
>> Logs:
>> /tmp/gang/hive.log
>> FAILED: Execution Error, return code 2 from
>>org.apache.hadoop.hive.ql.exec.MapRedTask
>> But actually local mr job in
>>/tmp/gang/gang_20120808181010_b716b5fb-5b8f-49d2-94e9-95bb8f465342.log
>
>--
>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] [Work logged] (HIVE-3371) Local mode errors point to the wrong file

[Gang Tim Liu (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HIVE-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel\#worklog-{worklog.getId()}
 ]

Gang Tim Liu logged work on HIVE-3371:
--

Author: Gang Tim Liu
Created on: 09/Aug/12 23:08
Start Date: 09/Aug/12 23:08
Worklog Time Spent: 48h 

Issue Time Tracking
---

Worklog Id: (was: 13834)
Time Spent: 48h
Remaining Estimate: 0h

> Local mode errors point to the wrong file
> -
>
> Key: HIVE-3371
> URL: https://issues.apache.org/jira/browse/HIVE-3371
> Project: Hive
>  Issue Type: Bug
>  Components: CLI
>Reporter: Gang Tim Liu
>Assignee: Gang Tim Liu
>Priority: Minor
> Attachments: hive-3371
>
>  Time Spent: 48h
>  Remaining Estimate: 0h
>
>  This is a classic example of a query that fails due to a bad udf in local 
> mode:
> Ended Job = job_local_0001 with errors
> Error during job, obtaining debugging information...
> Execution failed with exit status: 2
> Obtaining error information
> Task failed!
> Task ID:
>   Stage-1
> Logs:
> /tmp/gang/hive.log
> FAILED: Execution Error, return code 2 from 
> org.apache.hadoop.hive.ql.exec.MapRedTask
> But actually local mr job in 
> /tmp/gang/gang_20120808181010_b716b5fb-5b8f-49d2-94e9-95bb8f465342.log

--
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] [Updated] (HIVE-3371) Local mode errors point to the wrong file

[Gang Tim Liu (JIRA)]

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

Gang Tim Liu updated HIVE-3371:
---

Attachment: hive-3371

> Local mode errors point to the wrong file
> -
>
> Key: HIVE-3371
> URL: https://issues.apache.org/jira/browse/HIVE-3371
> Project: Hive
>  Issue Type: Bug
>  Components: CLI
>Reporter: Gang Tim Liu
>Assignee: Gang Tim Liu
>Priority: Minor
> Attachments: hive-3371
>
>
>  This is a classic example of a query that fails due to a bad udf in local 
> mode:
> Ended Job = job_local_0001 with errors
> Error during job, obtaining debugging information...
> Execution failed with exit status: 2
> Obtaining error information
> Task failed!
> Task ID:
>   Stage-1
> Logs:
> /tmp/gang/hive.log
> FAILED: Execution Error, return code 2 from 
> org.apache.hadoop.hive.ql.exec.MapRedTask
> But actually local mr job in 
> /tmp/gang/gang_20120808181010_b716b5fb-5b8f-49d2-94e9-95bb8f465342.log

--
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-3371) Local mode errors point to the wrong file

[Gang Tim Liu (JIRA)]

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

Gang Tim Liu commented on HIVE-3371:


https://reviews.facebook.net/D4575

> Local mode errors point to the wrong file
> -
>
> Key: HIVE-3371
> URL: https://issues.apache.org/jira/browse/HIVE-3371
> Project: Hive
>  Issue Type: Bug
>  Components: CLI
>Reporter: Gang Tim Liu
>Assignee: Gang Tim Liu
>Priority: Minor
>
>  This is a classic example of a query that fails due to a bad udf in local 
> mode:
> Ended Job = job_local_0001 with errors
> Error during job, obtaining debugging information...
> Execution failed with exit status: 2
> Obtaining error information
> Task failed!
> Task ID:
>   Stage-1
> Logs:
> /tmp/gang/hive.log
> FAILED: Execution Error, return code 2 from 
> org.apache.hadoop.hive.ql.exec.MapRedTask
> But actually local mr job in 
> /tmp/gang/gang_20120808181010_b716b5fb-5b8f-49d2-94e9-95bb8f465342.log

--
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: Review Request: This function overloads the current DateDiff(expr1, expr2) by adding another parameter to specify the units.

[Shefali Vohra]

> On Aug. 7, 2012, 12:56 a.m., Ashutosh Chauhan wrote:
> > trunk/ql/src/java/org/apache/hadoop/hive/ql/udf/UDFDateDiff.java, line 312
> > 
> >
> > Looks like this function is not used anywhere. Please remove it.

fixed!


> On Aug. 7, 2012, 12:56 a.m., Ashutosh Chauhan wrote:
> > trunk/ql/src/java/org/apache/hadoop/hive/ql/udf/UDFDateDiff.java, line 340
> > 
> >
> > Looks like this function is not used anywhere. Please, remove it.

fixed!


> On Aug. 7, 2012, 12:56 a.m., Ashutosh Chauhan wrote:
> > trunk/ql/src/java/org/apache/hadoop/hive/ql/udf/UDFDateDiff.java, line 180
> > 
> >
> > Avoid unnecessary object creation. Do, Date date1 = 
> > resolveDate(dateObj1, unit) which is more appropriate. Similarly for date2.

fixed!


> On Aug. 7, 2012, 12:56 a.m., Ashutosh Chauhan wrote:
> > trunk/ql/src/java/org/apache/hadoop/hive/ql/udf/UDFDateDiff.java, line 57
> > 
> >
> > Instead of these enums, can we use these ints instead 
> > http://docs.oracle.com/javase/6/docs/api/constant-values.html#java.text.DateFormat
> >  ?
> > 
> > Also, I don't think microseconds make sense, we don't have that 
> > precision in any case.

not every unit supported has an int associated with it, so does it still make 
sense to use these values? Also, is it ideal to use these ints when not 
everyone necessarily knows that, for example, 1 = year and 6 = minute?


> On Aug. 7, 2012, 12:56 a.m., Ashutosh Chauhan wrote:
> > trunk/ql/src/java/org/apache/hadoop/hive/ql/udf/UDFDateDiff.java, line 65
> > 
> >
> > Lets get rid of formatter variable, add default format ("-MM-dd") 
> > as first format in dateFormats and use formatLong() for all formats

The way formatLong() works is that it goes through each of those formats in 
chronological order. The reason is that a timestamp in the form -MM-dd 
HH:mm:ss could fit both -MM-dd HH:mm:ss and -MM-dd formats. I don't 
want something to check if -MM-dd is appropriate and ignore the HH:mm:ss 
unnecessarily. Do you think including the formatter variable as index 0 in the 
array is still the best option?


- Shefali


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/6027/#review9924
---


On July 18, 2012, 12:56 a.m., Shefali Vohra wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/6027/
> ---
> 
> (Updated July 18, 2012, 12:56 a.m.)
> 
> 
> Review request for hive and Ashutosh Chauhan.
> 
> 
> Description
> ---
> 
> Parameters
>  This function overloads the current DateDiff(expr1, expr2) by adding another 
> parameter to specify the units. It takes 3 parameters. The first two are 
> timestamps, and the formats accepted are:
>  -MM-dd
>  -MM-dd HH:mm:ss
>  -MM-dd HH:mm:ss.milli
> 
> These are the formats accepted by the current DateDiff(expr1, expr2) function 
> and allow for that consistency. The accepted data types for the timestamp 
> will be Text, TimestampWritable, Date, and String, just as with the already 
> existing function.
> 
> The third parameter is the units the user wants the response to be in. 
> Acceptable units are:
>  Microsecond
>  Millisecond
>  Second
>  Minute
>  Hour
>  Day
>  Week
>  Month
>  Quarter
>  Year
> 
> When calculating the difference, the full timestamp is used when the 
> specified unit is hour or smaller (microsecond, millisecond, second, minute, 
> hour), and only the date part is used if the unit is day or larger (day, 
> week, month, quarter, year). If for the smaller units the time is not 
> specified and the format -MM-dd is used, the time 00:00:00.0 is used. 
> Leap years are accounted for by the Calendar class in Java, which inherently 
> addresses the issue.
> 
> The assumption is made that all these time parameters are in the same time 
> zone.
> 
> Return Value
>  The function returns expr1 - expr2 expressed as an int in the units 
> specified.
> 
> Hive vs. SQL
>  SQL also has a DateDiff() function with some more acceptable units. The 
> order of parameters is different between SQL and Hive. The reason for this is 
> that Hive already has a DateDiff() function with the same first two 
> parameters, and having this order here allows for that consistency within 
> Hive.
> 
> Example Query
>  hive > DATEDIFF(DATE_FIELD, '2012-06-01', ‘day’); 
> 
> Diagnostic Error Messages
>  Invalid table alias or column name 

Hive-trunk-h0.21 - Build # 1599 - Still Failing

[Apache Jenkins Server]

Changes for Build #1598
[cws] HIVE-2789. query_properties.q contains non-deterministic queries 
(Zhenxiao Luo via cws)


Changes for Build #1599



6 tests failed.
FAILED:  
org.apache.hadoop.hive.cli.TestNegativeCliDriver.testNegativeCliDriver_script_broken_pipe1

Error Message:
Unexpected exception See build/ql/tmp/hive.log, or try "ant test ... 
-Dtest.silent=false" to get more logs.

Stack Trace:
junit.framework.AssertionFailedError: Unexpected exception
See build/ql/tmp/hive.log, or try "ant test ... -Dtest.silent=false" to get 
more logs.
at junit.framework.Assert.fail(Assert.java:50)
at 
org.apache.hadoop.hive.cli.TestNegativeCliDriver.testNegativeCliDriver_script_broken_pipe1(TestNegativeCliDriver.java:10849)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at junit.framework.TestSuite.run(TestSuite.java:238)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:518)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1052)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:906)


REGRESSION:  
org.apache.hadoop.hive.ql.exec.TestStatsPublisherEnhanced.testStatsPublisherOneStat

Error Message:
null

Stack Trace:
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:48)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertTrue(Assert.java:27)
at 
org.apache.hadoop.hive.ql.exec.TestStatsPublisherEnhanced.testStatsPublisherOneStat(TestStatsPublisherEnhanced.java:81)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at junit.framework.TestSuite.run(TestSuite.java:238)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:518)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1052)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:906)


REGRESSION:  
org.apache.hadoop.hive.ql.exec.TestStatsPublisherEnhanced.testStatsPublisher

Error Message:
null

Stack Trace:
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:48)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertTrue(Assert.java:27)
at 
org.apache.hadoop.hive.ql.exec.TestStatsPublisherEnhanced.testStatsPublisher(TestStatsPublisherEnhanced.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at junit.framework.TestSuite.run(TestSuite.java:238)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:518)
at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.l

[jira] [Commented] (HIVE-3216) DateDiff UDF overload with a unit parameter

[Shefali Vohra (JIRA)]

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

Shefali Vohra commented on HIVE-3216:
-

Ashutosh, I have left some comments on the review board. Can you please take a 
look when you get a chance?

> DateDiff UDF overload with a unit parameter
> ---
>
> Key: HIVE-3216
> URL: https://issues.apache.org/jira/browse/HIVE-3216
> Project: Hive
>  Issue Type: Improvement
>  Components: SQL, UDF
>Affects Versions: 0.10.0, 0.9.1
>Reporter: Shefali Vohra
>Assignee: Shefali Vohra
>Priority: Minor
>  Labels: date, patch, sql, timestamp, udf
> Fix For: 0.9.1
>
> Attachments: HIVE-3216.1.patch.txt
>
>
> *Parameters*
> This function overloads the current DateDiff(expr1, expr2) by adding another 
> parameter to specify the units. It takes 3 parameters. The first two are 
> timestamps, and the formats accepted are:
> -MM-dd
> -MM-dd HH:mm:ss
> -MM-dd HH:mm:ss.milli
> These are the formats accepted by the current DateDiff(expr1, expr2) function 
> and allow for that consistency. The accepted data types for the timestamp 
> will be Text, TimestampWritable, Date, and String, just as with the already 
> existing function.
> The third parameter is the units the user wants the response to be in. 
> Acceptable units are:
> Microsecond
> Millisecond
> Second
> Minute
> Hour
> Day
> Week
> Month
> Quarter
> Year
> When calculating the difference, the full timestamp is used when the 
> specified unit is hour or smaller (microsecond, millisecond, second, minute, 
> hour), and only the date part is used if the unit is day or larger (day, 
> week, month, quarter, year). If for the smaller units the time is not 
> specified and the format -MM-dd is used, the time 00:00:00.0 is used. 
> Leap years are accounted for by the Calendar class in Java, which inherently 
> addresses the issue.
> The assumption is made that all these time parameters are in the same time 
> zone.
> *Return Value*
> The function returns expr1 -  expr2 expressed as an int in the units 
> specified.
> *Hive vs. SQL*
> SQL also has a DateDiff() function with some more acceptable units. The order 
> of parameters is different between SQL and Hive. The reason for this is that 
> Hive already has a DateDiff() function with the same first two parameters, 
> and having this order here allows for that consistency within Hive.
> *Example Query*
> hive > DATEDIFF(DATE_FIELD, '2012-06-01', ‘day’); 
> *Diagnostic Error Messages*
> Invalid table alias or column name reference
> Table not found

--
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-3341) Making hive tests run against different MR versions

[Carl Steinbach (JIRA)]

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

Carl Steinbach commented on HIVE-3341:
--

@Sushanth: Left some comments on phabricator.

@Ashutosh: I got an error when I tried to cancel this patch. It also looks like 
I can't create new tickets. Have you encountered the same problems?

> Making hive tests run against different MR versions
> ---
>
> Key: HIVE-3341
> URL: https://issues.apache.org/jira/browse/HIVE-3341
> Project: Hive
>  Issue Type: Bug
>Reporter: Sushanth Sowmyan
>Assignee: Sushanth Sowmyan
>
> After we build hive, we want to have the ability to run unit tests against 
> specific hadoop versions. Currently, the classpath constructed has multiple 
> hadoop jars, which makes compiling okay, but running non-deterministic.
> An example is HIVE-3156, where running against 0.23 shows issues with a 
> couple of tests (which should either be shimmed out, or separated into 
> directories the way it's done in the shims/ directory) - It would also be 
> nice to find these issues out at test-compile time itself, rather than having 
> them fail at test runtime.

--
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] [Updated] (HIVE-3341) Making hive tests run against different MR versions

[Carl Steinbach (JIRA)]

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

Carl Steinbach updated HIVE-3341:
-

Status: Open  (was: Patch Available)

@Sushanth: I left some comments on phabricator. Thanks.

> Making hive tests run against different MR versions
> ---
>
> Key: HIVE-3341
> URL: https://issues.apache.org/jira/browse/HIVE-3341
> Project: Hive
>  Issue Type: Bug
>Reporter: Sushanth Sowmyan
>Assignee: Sushanth Sowmyan
>
> After we build hive, we want to have the ability to run unit tests against 
> specific hadoop versions. Currently, the classpath constructed has multiple 
> hadoop jars, which makes compiling okay, but running non-deterministic.
> An example is HIVE-3156, where running against 0.23 shows issues with a 
> couple of tests (which should either be shimmed out, or separated into 
> directories the way it's done in the shims/ directory) - It would also be 
> nice to find these issues out at test-compile time itself, rather than having 
> them fail at test runtime.

--
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] [Updated] (HIVE-3338) Archives broken for hadoop 1.0

[Vikram Dixit K (JIRA)]

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

Vikram Dixit K updated HIVE-3338:
-

Attachment: HIVE-3338_2.patch

This resolves the issues in 1.0. The renaming of an archived table does not 
work in case of 20. This patch does not address that issue.

> Archives broken for hadoop 1.0
> --
>
> Key: HIVE-3338
> URL: https://issues.apache.org/jira/browse/HIVE-3338
> Project: Hive
>  Issue Type: Bug
>  Components: Shims
>Affects Versions: 0.9.0
>Reporter: Vikram Dixit K
> Attachments: HIVE-3338.patch, HIVE-3338_2.patch
>
>
> Hadoop archiving through hive is broken for 1.0. The hadoop archive command 
> line and paths have changed for 1.0 and were not addressed in the shim layer.

--
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-3341) Making hive tests run against different MR versions

[Ashutosh Chauhan (JIRA)]

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

Ashutosh Chauhan commented on HIVE-3341:


@Sushanth,
Can you upload the patch here. Phabricator doesnt let you download a patch.

> Making hive tests run against different MR versions
> ---
>
> Key: HIVE-3341
> URL: https://issues.apache.org/jira/browse/HIVE-3341
> Project: Hive
>  Issue Type: Bug
>Reporter: Sushanth Sowmyan
>Assignee: Sushanth Sowmyan
>
> After we build hive, we want to have the ability to run unit tests against 
> specific hadoop versions. Currently, the classpath constructed has multiple 
> hadoop jars, which makes compiling okay, but running non-deterministic.
> An example is HIVE-3156, where running against 0.23 shows issues with a 
> couple of tests (which should either be shimmed out, or separated into 
> directories the way it's done in the shims/ directory) - It would also be 
> nice to find these issues out at test-compile time itself, rather than having 
> them fail at test runtime.

--
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-3344) hive compilation on hadoop 23 is failing

[Namit Jain (JIRA)]

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

Namit Jain commented on HIVE-3344:
--

@Carl, were you able to get the test running on hadoop 23 ?

If I want to test a particular .q file for hadoop 23, what is the exact command 
to run ?

> hive compilation on hadoop 23 is failing
> 
>
> Key: HIVE-3344
> URL: https://issues.apache.org/jira/browse/HIVE-3344
> Project: Hive
>  Issue Type: Bug
>Reporter: Namit Jain
>
> I tried the following:
> ant -Dhadoop.version=0.23.0 package
> ant -Dhadoop.version=0.23.1 package
> But, I am running into some problem all the time

--
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] [Deleted] (HIVE-3349) semi-colon in comments in .q file does not work

[Namit Jain (JIRA)]

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

Namit Jain deleted HIVE-3349:
-


> semi-colon in comments in .q file does not work
> ---
>
> Key: HIVE-3349
> URL: https://issues.apache.org/jira/browse/HIVE-3349
> Project: Hive
>  Issue Type: Bug
>Reporter: Namit Jain
>
> -- comment ;
> -- comment
> select count(1) from src;
> The above test file fails

--
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] [Deleted] (HIVE-3350) semi-colon in comments in .q file does not work

[Namit Jain (JIRA)]

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

Namit Jain deleted HIVE-3350:
-


> semi-colon in comments in .q file does not work
> ---
>
> Key: HIVE-3350
> URL: https://issues.apache.org/jira/browse/HIVE-3350
> Project: Hive
>  Issue Type: Bug
>Reporter: Namit Jain
>
> -- comment ;
> -- comment
> select count(1) from src;
> The above test file fails

--
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] [Deleted] (HIVE-3352) semi-colon in comments dont work

[Namit Jain (JIRA)]

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

Namit Jain deleted HIVE-3352:
-


> semi-colon in comments dont work
> 
>
> Key: HIVE-3352
> URL: https://issues.apache.org/jira/browse/HIVE-3352
> Project: Hive
>  Issue Type: Bug
>Reporter: Namit Jain
>
> -- comment ;
> -- comment
> select count(1) from src;
> The above query fails

--
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] [Deleted] (HIVE-3351) semi-colon in comments in .q file does not work

[Namit Jain (JIRA)]

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

Namit Jain deleted HIVE-3351:
-


> semi-colon in comments in .q file does not work
> ---
>
> Key: HIVE-3351
> URL: https://issues.apache.org/jira/browse/HIVE-3351
> Project: Hive
>  Issue Type: Bug
>Reporter: Namit Jain
>
> -- comment ;
> -- comment
> select count(1) from src;
> The above test file fails

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

Build failed in Jenkins: Hive-0.9.1-SNAPSHOT-h0.21-keepgoing=false #101

[Apache Jenkins Server]

See 


--
[...truncated 10115 lines...]
 [echo] Project: odbc
 [copy] Warning: 

 does not exist.

ivy-resolve-test:
 [echo] Project: odbc

ivy-retrieve-test:
 [echo] Project: odbc

compile-test:
 [echo] Project: odbc

create-dirs:
 [echo] Project: serde
 [copy] Warning: 

 does not exist.

init:
 [echo] Project: serde

ivy-init-settings:
 [echo] Project: serde

ivy-resolve:
 [echo] Project: serde
[ivy:resolve] :: loading settings :: file = 

[ivy:report] Processing 

 to 


ivy-retrieve:
 [echo] Project: serde

dynamic-serde:

compile:
 [echo] Project: serde

ivy-resolve-test:
 [echo] Project: serde

ivy-retrieve-test:
 [echo] Project: serde

compile-test:
 [echo] Project: serde
[javac] Compiling 26 source files to 

[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.

create-dirs:
 [echo] Project: service
 [copy] Warning: 

 does not exist.

init:
 [echo] Project: service

ivy-init-settings:
 [echo] Project: service

ivy-resolve:
 [echo] Project: service
[ivy:resolve] :: loading settings :: file = 

[ivy:report] Processing 

 to 


ivy-retrieve:
 [echo] Project: service

compile:
 [echo] Project: service

ivy-resolve-test:
 [echo] Project: service

ivy-retrieve-test:
 [echo] Project: service

compile-test:
 [echo] Project: service
[javac] Compiling 2 source files to 


test:
 [echo] Project: hive

test-shims:
 [echo] Project: hive

test-conditions:
 [echo] Project: shims

gen-test:
 [echo] Project: shims

create-dirs:
 [echo] Project: shims
 [copy] Warning: 

 does not exist.

init:
 [echo] Project: shims

ivy-init-settings:
 [echo] Project: shims

ivy-resolve:
 [echo] Project: shims
[ivy:resolve] :: loading settings :: file = 

[ivy:report] Processing 

 to 


ivy-retrieve:
 [echo] Project: shims

compile:
 [echo] Project: shims
 [echo] Building shims 0.20

build_shims:
 [echo] Project: shims
 [echo] Compiling 

 against hadoop 0.20.2 
(

ivy-init-settings:
 [echo] Project: shims

ivy-resolve-hadoop-shim:
 [echo] Project: shims
[ivy:resolve] :: loading settings :: file = 


ivy-retrieve-hadoop-shim:
 [echo] Project: shims
 [echo] Building shims 0.20S

build_shims:
 [echo] Project: shims
 [echo] Compiling 

[jira] [Commented] (HIVE-565) support for buckets in the table being inserted

[Lianhui Wang (JIRA)]

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

Lianhui Wang commented on HIVE-565:
---

i think before that we need to store the bucketing-file mapping information in 
mysql
or
we can use the file name to identify the bucket number.
have any other way?

> support for buckets in the table being inserted
> ---
>
> Key: HIVE-565
> URL: https://issues.apache.org/jira/browse/HIVE-565
> Project: Hive
>  Issue Type: Improvement
>  Components: Query Processor
>Affects Versions: 0.4.0
>Reporter: Namit Jain
>
> While inserting into a bucketed table, the bucketing property should be 
> maintained.
> Currently, it is lost.

--
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] [Deleted] (HIVE-3353) semi-colon in comments dont work

[Namit Jain (JIRA)]

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

Namit Jain deleted HIVE-3353:
-


> semi-colon in comments dont work
> 
>
> Key: HIVE-3353
> URL: https://issues.apache.org/jira/browse/HIVE-3353
> Project: Hive
>  Issue Type: Bug
>Reporter: Namit Jain
>


--
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] [Deleted] (HIVE-3354) semicolon in comments dont work

[Namit Jain (JIRA)]

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

Namit Jain deleted HIVE-3354:
-


> semicolon in comments dont work
> ---
>
> Key: HIVE-3354
> URL: https://issues.apache.org/jira/browse/HIVE-3354
> Project: Hive
>  Issue Type: Bug
>Reporter: Namit Jain
>


--
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-3361) Warning printed at error level

[Philip Tromans (JIRA)]

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

Philip Tromans commented on HIVE-3361:
--

(apologies for the dupes, JIRA was giving me a "Error creating issue: 
com.atlassian.jira.util.RuntimeIOException: java.io.IOException: read past EOF" 
when I clicked submit, so I thought it hadn't worked...). Can a committer 
please delete these dups?

> Warning printed at error level
> --
>
> Key: HIVE-3361
> URL: https://issues.apache.org/jira/browse/HIVE-3361
> Project: Hive
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 0.9.0
>Reporter: Philip Tromans
>Assignee: Philip Tromans
>Priority: Trivial
>
> In org.apache.hadoop.hive.ql.plan.ExprNodeGenericFuncDesc.newInstance(), the 
> message:
> WARNING: Comparing a bigint and a string may result in a loss of precision.
> is emitted at Log.ERROR level. This should probably be done at Log.WARN level.

--
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] [Updated] (HIVE-3141) Bug in SELECT query

[Ajesh Kumar (JIRA)]

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

Ajesh Kumar updated HIVE-3141:
--

Attachment: select_syntax.q.out
select_syntax.q

Adding q file and q.out file for negative test.

> Bug in SELECT query
> ---
>
> Key: HIVE-3141
> URL: https://issues.apache.org/jira/browse/HIVE-3141
> Project: Hive
>  Issue Type: Bug
>  Components: CLI
>Affects Versions: 0.9.0
> Environment: OS: Ubuntu 
> Hive version: hive-0.7.1-cdh3u2
> Hadoop : hadoop-0.20.2
>Reporter: ASK
>Priority: Minor
>  Labels: patch
> Attachments: HIVE-3141.1.patch.txt, Hive_bug_3141_resolution.pdf, 
> select_syntax.q, select_syntax.q.out
>
>
> When i try to execute select *(followed by any alphanumeric character) from 
> table , query is throwing some issues. It display the result for select *
> It doesnot happen when only numbers follow the *

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

Inconsistencies around casting booleans

[Philip Tromans]

Hi all,

We've been using boolean types in partition values (not the best idea,
I know), and we've noticed a few inconsistencies around casting:

SELECT cast('true' as boolean), cast('false' as boolean), cast(true as
string), cast(false as string), cast(cast(false as string) as boolean)
FROM test

returns

truetrueTRUEFALSE   true

The current logic in UDFToBoolean is that a string is false if it's
empty, and true otherwise. This isn't mirrored in UDFToString(), and
hence the inconsistency above.

I'm happy to file a JIRA to change this to something more reasonable,
but I guess this would break backwards compatibility. What are
people's opinions on this?

Cheers,

Phil.

Inconsistencies around casting booleans

[Philip Tromans]

Hi all,

We've been using boolean types in partition values (not the best idea,
I know), and we've noticed a few inconsistencies around casting:

select cast('true' as boolean), cast('false' as boolean), cast(true as
string), cast(false as string), cast(cast(false as string) as boolean)
from test

truetrueTRUEFALSE   true

The current logic in UDFToBoolean is that a string is false if it's
empty, and true otherwise. This isn't mirrored in UDFToString(), and
hence the inconsistency above.

I'm happy to file a JIRA to change this to something more reasonable,
but I guess this would break backwards compatibility. What are
people's opinions on this?

Cheers,

Phil.