asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Carey <dtab...@gmail.com>
Subject Re: Strange Comparison Allowed
Date Thu, 20 Aug 2015 07:54:20 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message