asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Taewoo Kim <wangs...@gmail.com>
Subject Re: bug: string-concat
Date Sat, 15 Aug 2015 23:15:53 GMT
I found out that this issue issue is related to the issue of extracting one
element in the OrderedList. As we can see in the
https://code.google.com/p/asterixdb/wiki/Serialization, if a list has
heterogeneous elements, each element itself includes the type tag. However,
the "StringConcatDescriptor" assumes that it only deals with a list with
homogeneous elements. So, its error is including the type tag when
calculating the string length. When Wail changed the second element as the
string, that error did not happen since the type tag was removed for that
list. I will submit the patch.

Summary: the String concat function handler checks whether its input is a
list (unordered/ordered) and its elements are string or null. However, it
assumes that the list includes only one type of elements.


Best,
Taewoo

On Fri, Aug 14, 2015 at 11:07 PM, Taewoo Kim <wangsaeu@gmail.com> wrote:

> That's the strange part. The code says it checks the field type. In fact,
> it doesn't. Maybe need to debug the real AQL.
>
> Best,
> Taewoo
>
> On Fri, Aug 14, 2015 at 10:55 PM, Mike Carey <dtabass@gmail.com> wrote:
>
>> This doesn't seem to match the observed real behavior?
>>
>>
>> On 8/14/15 1:09 PM, Taewoo Kim wrote:
>>
>>> In StringConcatDescriptor that handles string-concat function, it checks
>>> whether the input is an ordered list or an unordered list. If so, it
>>> checks
>>> each of element is STRING or NULL type. If not, it generates an
>>> exception.
>>> I am not sure how this exception could happen. Maybe need to dig in to
>>> check it.
>>>
>>> if (itemType != ATypeTag.STRING) {
>>> if (itemType == ATypeTag.NULL) {
>>> nullSerde.serialize(ANull.NULL, out);
>>> return;
>>> }
>>> throw new
>>> AlgebricksException(AsterixBuiltinFunctions.STRING_CONCAT.getName()
>>> + ": expects type STRING/NULL for the list item but got " + itemType);
>>> }
>>>
>>> By the way, to answer the Mike's question, I think each author needs to
>>> check its input type and does the proper handling like this StringConcat
>>> does. Based on my relatively short(?) experiences, most functions check
>>> these input types internally.
>>>
>>>
>>>
>>> Best,
>>> Taewoo
>>>
>>> On Fri, Aug 14, 2015 at 12:57 PM, Mike Carey <dtabass@gmail.com> wrote:
>>>
>>> PS (to my previous note) - I suspect this function is assuming the bits
>>>> it's passed are a string, and not checking to ensure that first.  One
>>>> question related to this would be whether the desired behavior on the
>>>> second record would be a runtime type error or the treatment of the
>>>> offending data as null (which then raises the issue of null semantics
>>>> for
>>>> functions) - I would be inclined (w/o too much thought yet) to say that
>>>> this should raise a runtime type error.  Another question related to
>>>> this
>>>> is whether the author of each function should have to handle wrong types
>>>> and nulls for each parameter each time - or live in a function
>>>> invocation
>>>> wrapping framework that provides some default answers for those
>>>> behaviors?
>>>> Thoughts?
>>>>
>>>> On 8/14/15 8:45 AM, Wail Alkowaileet wrote:
>>>>
>>>> Hello Team,
>>>>>
>>>>> I was testing some of Asterix built-in functions and I ran into a bug
>>>>> if
>>>>> the fields are heterogeneous.
>>>>>
>>>>> Reproduce the Problem:
>>>>> let $k := [{"a":1, "b":"hello"}, {"a":2, "b":{"k": [1,2,2]}}]
>>>>> for $x in $k
>>>>> where $x.a = 1
>>>>> return string-concat([$x.b, " world"])
>>>>>
>>>>> Result:
>>>>> summary: "edu.uci.ics.hyracks.api.exceptions.HyracksDataException:
>>>>> java.lang.ArrayIndexOutOfBoundsException: 64
>>>>>
>>>>> if the 2nd "b" is string as well, the issue doesn't appear.
>>>>>
>>>>>
>>>>> logs attached.
>>>>> --
>>>>>
>>>>> *Regards,*
>>>>> Wail Alkowaileet
>>>>>
>>>>>
>>>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message