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 06:07:54 GMT
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