Mailing-List: contact dev-help@hive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hive.apache.org
Date: Tue, 17 Sep 2013 20:47:51 +0000 (UTC)
From: "Sergey Shelukhin (JIRA)" <jira@apache.org>
To: hive-dev@hadoop.apache.org
Message-ID: <JIRA.12669108.1379450683266.149086.1379450871665@arcas>
In-Reply-To: <JIRA.12669108.1379450683266@arcas>
References: <JIRA.12669108.1379450683266@arcas>
Subject: [jira] [Commented] (HIVE-5304) JDO and SQL filters can both return
 different results for string compares depending on underlying datastore
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Sergey Shelukhin commented on HIVE-5304:
----------------------------------------

Actually, all names - I see show indexes order also changes in some queries, etc.
                
> JDO and SQL filters can both return different results for string compares depending on underlying datastore
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: HIVE-5304
>                 URL: https://issues.apache.org/jira/browse/HIVE-5304
>             Project: Hive
>          Issue Type: Bug
>          Components: Metastore
>            Reporter: Sergey Shelukhin
>
> Hive uses JDOQL filters to optimize partition retrieval; recently direct SQL was added to optimize it further. Both of these methods may end up pushing StringCol op 'SomeString' to underlying SQL datastore. Many paths also pushes order by-s, although these are not as problematic.
> The problem is that different datastores handle string compares differently. 
> While testing on Postgres, I see that results in different things, from innocent like order changes in "show partitions", to more serious like 
> {code}
>  alter table ptestfilter drop partition (c>='US', d<='2')
> {code}
> in drop_partitions_filter.q - in Derby, with which the .q.out file was generated, it drops "c=Uganda/d=2"; this also passes on MySQL (I ran tests with autocreated db); on Postgres with a db from the script it doesn't.
> Looks like we need to enforce collation in partition names and part_key_values-es; both in the create scripts, as well as during autocreate (via package.jdo?)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira