asterixdb-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Taewoo Kim (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ASTERIXDB-1234) Currently allowing (and botching) non-atomic field comparisons
Date Wed, 23 Dec 2015 23:56:46 GMT

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

Taewoo Kim commented on ASTERIXDB-1234:
---------------------------------------

I just had a conversation with Mike. It seems like there are two possible solutions: 1) change
IBinaryComparator.compare() to return four discrete values (-1: less than, 0: equal, 1: greater
than, -99: two values are not comparable.) and 2) introduce comparabilityCheck() functionality
before doing actual comparison in a join. The first method 1) looks more simpler than the
other method since the other method requires to create a new interface and we need to pass
this functionality from Asterix to Hyracks. In addition, two comparisons should occur (one
for type-tag checking, one for actual value comparison). I am going to check the codebase
to see the possible effect of the first method.  

> Currently allowing (and botching) non-atomic field comparisons
> --------------------------------------------------------------
>
>                 Key: ASTERIXDB-1234
>                 URL: https://issues.apache.org/jira/browse/ASTERIXDB-1234
>             Project: Apache AsterixDB
>          Issue Type: Bug
>          Components: AsterixDB, Optimizer, Translator - AQL
>            Reporter: Michael J. Carey
>            Assignee: Taewoo Kim
>
> In the ADM/AQL 101 demo, the following query "works" and should not:
> use dataverse TinySocial;
> for $t1 in dataset TweetMessages
> for $t2 in dataset TweetMessages
> where $t1.referred-topics = $t2.referred-topics
> return {
>   "topics1": $t1.referred-topics,
>   "topics2":$t2.referred-topics
> }
> Notice that this is comparing two non-atomic (unordered list) fields.  Eventually we
should support deep equality for = and return null for <, etc.
> Currently the system thinks the fields are comparable because they have the same type
tag - and then it does a bytewise comparison, which is wrong.
> For now we should disallow (return null) comparisons of records or lists;
> in the future we should support deep equality.



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

Mime
View raw message