asterixdb-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael J. Carey (JIRA)" <>
Subject [jira] [Commented] (ASTERIXDB-1234) Currently allowing (and botching) non-atomic field comparisons
Date Thu, 18 Aug 2016 23:39:20 GMT


Michael J. Carey commented on ASTERIXDB-1234:

Two things:

1. Indeed the issue still does exist, as

     use dataverse TinySocial;
     for $t1 in dataset ChirpMessages
     for $t2 in dataset ChirpMessages
     where $t1.referredTopics = $t2.referredTopics
         and $t1.chirpId < $t2.chirpId
     return {
                   "t1":$t1.chirpId, "topics1": $t1.referredTopics,
                   "t2":$t2.chirpId, "topics2":$t2.referredTopics

in my new version of TinySocial returns

     { "t1": "3", "topics1": {{ "motorola", "speed" }}, "t2": "5", 
"topics2": {{ "motorola", "speed" }} }

but then if you reverse the (semantically meaningless) order of the 
items for one of the Chirps, the result is empty.

2. We're kind of hoping that everyone will check their JIRA issues (in 
parallel with one another) much like this. With > 400 issues, it would 
have been a little tedious for Till and I to currency-check them each 
before tagging them.  :-)



> Currently allowing (and botching) non-atomic field comparisons
> --------------------------------------------------------------
>                 Key: ASTERIXDB-1234
>                 URL:
>             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

View raw message