You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@asterixdb.apache.org by "Taewoo Kim (JIRA)" <ji...@apache.org> on 2016/01/06 23:51:39 UTC
[jira] [Commented] (ASTERIXDB-1234) Currently allowing (and
botching) non-atomic field comparisons
[ https://issues.apache.org/jira/browse/ASTERIXDB-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15086436#comment-15086436 ]
Taewoo Kim commented on ASTERIXDB-1234:
---------------------------------------
Mike's suggestion is dividing the universal comparator into two - one can support a total ordering, and the other returns non-comparable. Asterix passes the appropriate comparator to Hyracks (e.g., passes the total-ordering support comparator to external-sort).
> 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)