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 09:35:44 GMT
Yes, that makes sense. I will leave the deep-equal as is, wrt. equality for
now then.

Thanks,
-heri

> On Aug 20, 2015, at 9:54 AM, Mike Carey <dtabass@gmail.com> wrote:
> 
> I'm not sure we need to define a logical ordering of those - I'd prefer not - I would
just want to allow = as an operator on them.  (We have other things that aren't orderable,
e.g., points.)  We should think of them as being kind of like points or time intervals in
that sense.
> 
> On 8/19/15 11:42 PM, Heri Ramampiaro wrote:
>> 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