asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Heri Ramampiaro <heri...@gmail.com>
Subject Re: Strange Comparison Allowed
Date Thu, 20 Aug 2015 06:42:17 GMT
I can look into the extension of the deep-equal so that we can use it for ordering
lists and records, in addition to just returning a binary equality.

-heri


> On Aug 20, 2015, at 12:44 AM, Mike Carey <dtabass@gmail.com> wrote:
> 
> Phew!  And meanwhile we should incorporate Heri's work to allow meaningful
> non-atomic value comparisons and hash joining!
> On Aug 19, 2015 3:39 PM, "Taewoo Kim" <wangsaeu@gmail.com> wrote:
> 
>> Sorry for my poor memory. Mike is correct. I have checked the codebase.
>> Byte-to-byte comparison is should be only conducted for the order by case.
>> For equality operations, we do have protection. If you check
>> AbstractComparisonEvaluator and EqualityComparisonEvaluator class, it
>> checks whether the given two values are comparable first. If not, it just
>> return false. Therefore, in this case, INT > POINT returns FALSE. The
>> result is FALSE, based on the fact that INT and POINT can't be compared,
>> not based on the byte-by-byte level comparison.
>> 
>> Best,
>> Taewoo
>> 
>> On Wed, Aug 19, 2015 at 3:09 PM, Mike Carey <dtabass@gmail.com> wrote:
>> 
>>> This all sounds somewhat wrong to me!  It's not what I remember from
>> design
>>> discussions of old...  I don't think we should be doing byte by byte
>>> comparison between disparate types.  Why would users want or expect that?
>>> Note that I'm talking about predicate cases - not internal needs like
>> order
>>> by or routing of data.
>>> On Aug 19, 2015 11:47 AM, "Ildar Absalyamov" <ildar.absalyamov@gmail.com
>>> 
>>> wrote:
>>> 
>>>> @Steven
>>>> Index rewrite will not fire in this case, because of type mismatch.
>> Hence
>>>> it will fallback to non-indexed query results.
>>>> 
>>>> 2015-08-19 11:25 GMT-07:00 Taewoo Kim <wangsaeu@gmail.com>:
>>>> 
>>>>> @Steven: I never tried. However, it's worthwhile to check. If the
>> query
>>>>> semantic is correct, the optimizer will try to utilize the index
>>>> regardless
>>>>> of its type. My guess is, at the end, byte-by-byte comparison will
>>> occur.
>>>>> 
>>>>> Best,
>>>>> Taewoo
>>>>> 
>>>>> On Wed, Aug 19, 2015 at 11:19 AM, Steven Jacobs <sjaco002@ucr.edu>
>>>> wrote:
>>>>> 
>>>>>> I think this is because the serialized versions of the list have
>>> their
>>>>>> lengths among the beginning bytes, so this would make sense, since
>> we
>>>>> don't
>>>>>> have a comparator for lists.
>>>>>> 
>>>>>> @Taewoo-What about the case of an index search? Is it okay to pass
>>> the
>>>>>> wrong type to the search (which will obviously yield unknown
>> results)
>>>>>> 
>>>>>> Steven
>>>>>> 
>>>>>> On Wed, Aug 19, 2015 at 11:12 AM, Wail Alkowaileet <
>>> wael.y.k@gmail.com
>>>>> 
>>>>>> wrote:
>>>>>> 
>>>>>>> Actually I observed some strange behavior while comparing
>>>> orderedLists
>>>>> in
>>>>>>> the order by clause.
>>>>>>> 
>>>>>>> Input (dataset json):
>>>>>>> { "a": 1i32, "b": [ 1, "hello" ] }
>>>>>>> { "a": 2i32, "b": [ 1, "hello" ] }
>>>>>>> { "a": 3i32, "b": [ 1, "hi" ] }
>>>>>>> 
>>>>>>> Query:
>>>>>>> for $x in dataset json
>>>>>>> order by $x.b
>>>>>>> return $x
>>>>>>> 
>>>>>>> Result:
>>>>>>> { "a": 3i32, "b": [ 1, "hi" ] }
>>>>>>> { "a": 1i32, "b": [ 1, "hello" ] }
>>>>>>> { "a": 2i32, "b": [ 1, "hello" ] }
>>>>>>> 
>>>>>>> it seems the behavior is comparing by the length of the list
not
>>> the
>>>>>> values
>>>>>>> themselves? is it expected?
>>>>>>> 
>>>>>>> But if I do something like this:
>>>>>>> for $x in dataset json
>>>>>>> order by $x.b[1]
>>>>>>> return $x
>>>>>>> 
>>>>>>> Result:
>>>>>>> { "a": 1i32, "b": [ 1, "hello" ] }
>>>>>>> { "a": 2i32, "b": [ 1, "hello" ] }
>>>>>>> { "a": 3i32, "b": [ 1, "hi" ] }
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Wed, Aug 19, 2015 at 1:50 PM, Taewoo Kim <wangsaeu@gmail.com>
>>>>> wrote:
>>>>>>> 
>>>>>>>> Sorry. The direction of inequality operator was misleading.
>>> STRING
>>>> 13
>>>>>> is
>>>>>>>> smaller than (<) POINT 20.
>>>>>>>> 
>>>>>>>> Best,
>>>>>>>> Taewoo
>>>>>>>> 
>>>>>>>> On Wed, Aug 19, 2015 at 10:49 AM, Taewoo Kim <
>> wangsaeu@gmail.com
>>>> 
>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Yes. Type conversion (casting) only happens among numeric
>> types
>>>> so
>>>>>> far.
>>>>>>>>> Actually, since there is a type-tag, if you try to compare
>> two
>>>> non
>>>>>>>> numeric
>>>>>>>>> types, it stops the comparing as soon as it sees the
first
>> byte
>>>>> from
>>>>>>> both
>>>>>>>>> side since type-tag itself has the given order (e.g.,
STRING
>>> 13 >
>>>>>> POINT
>>>>>>>>> 20). This is required for ORDER BY, too.
>>>>>>>>> 
>>>>>>>>> Best,
>>>>>>>>> Taewoo
>>>>>>>>> 
>>>>>>>>> On Wed, Aug 19, 2015 at 10:45 AM, Steven Jacobs <
>>>> sjaco002@ucr.edu>
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> I see, so we are technically allowed to compare anything
to
>>>>>> anything?
>>>>>>>>>> 
>>>>>>>>>> Steven
>>>>>>>>>> 
>>>>>>>>>> On Wed, Aug 19, 2015 at 10:37 AM, Taewoo Kim <
>>>> wangsaeu@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> If there is no right comparator for the given
types
>> (STRING
>>> vs
>>>>>>> POINT),
>>>>>>>>>> then
>>>>>>>>>>> it does the "byte by byte" comparison.
>>>>>>>>>>> 
>>>>>>>>>>> Best,
>>>>>>>>>>> Taewoo
>>>>>>>>>>> 
>>>>>>>>>>> On Wed, Aug 19, 2015 at 10:32 AM, Steven Jacobs
<
>>>>> sjaco002@ucr.edu
>>>>>>> 
>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> This is currently working in master:
>>>>>>>>>>>> 
>>>>>>>>>>>> create type CSXType as closed {
>>>>>>>>>>>>  id: int32,
>>>>>>>>>>>>  csxid: string
>>>>>>>>>>>> }
>>>>>>>>>>>> create dataset CSX(CSXType) primary key id;
>>>>>>>>>>>> 
>>>>>>>>>>>> for $b in dataset('CSX')
>>>>>>>>>>>> where $b.id > point("3,5")
>>>>>>>>>>>> return $b;
>>>>>>>>>>>> 
>>>>>>>>>>>> Is this supposed to be working?
>>>>>>>>>>>> Steven
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> 
>>>>>>> *Regards,*
>>>>>>> Wail Alkowaileet
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Best regards,
>>>> Ildar
>>>> 
>>> 
>> 


Mime
View raw message