Surely looks like a bug, but I agree with Mike that there is a broader issue here. Similar to recently filed issue 926, which is supposed to rule out typing errors during compile time (if I understood correctly), there should exist a generic solution to check the types in the runtime. The current approach where type checking is responsibility of each function is combersome and error-prone. Moreover refactoring this type-checking becomes a nightmare, because it the logic is spread thinly across the codebase, I have encountered that (with function type computers though, but it’s the same problem) while doing the union-related metadata changes.
> On Aug 15, 2015, at 16:15, Taewoo Kim <[email protected]> wrote: > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>>>> >>>>>> >>>>> >>> >> Best regards, Ildar
