You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@asterixdb.apache.org by Mike Carey <dt...@gmail.com> on 2015/10/07 00:03:23 UTC
Re: Is it intended to skip the function-generated Null in the list?
Definitely not "works as designed". Sounds like a bug for sure! :-)
I can imagine use cases where one would like nulls included and use
cases where one would like nulls surpressed, in general - but fixing
this is step one!
On 10/6/15 2:52 PM, Jianfeng Jia wrote:
> Hi devs,
>
> I hit a failed test case in which I was building a list with the elements generated from a build-in function, as below,
>
> for $a in [
> starts-with("xyz", null),
> starts-with("xy", "x")
> ]
> return $a
>
> If any of the elements is Null, it will be omitted in the returned list, e.g. the above query returns the following result:
>
> [ true
> ]
>
> However if I explicitly add a null in the list, all the Nulls will be returned.
> the following query:
>
> for $a in [
> null,
> starts-with("xy", null),
> starts-with("xy", "x")
> ]
> return $a
>
> will return the expected result:
>
> [ null
> , null
> , true
> ]
> It applies for other similar functions which returns an option value.
> It seems like a bug. Anyone has any ideas about this problem?
>
>
> Best,
>
> Jianfeng Jia
> PhD Candidate of Computer Science
> University of California, Irvine
>
>
Re: Is it intended to skip the function-generated Null in the list?
Posted by Jianfeng Jia <ji...@gmail.com>.
Good to know the rule. It should be one of the reason.
However, it seems there are some other deeper “rules”. After I’ve changed the type computer result to OptionalABooleanType, it still showed the previous result.
Also I tried another OptionalABooleanType registered function, like string-concat, the similar problem appears again:
for $a in [
string-concat([null, "xyz"]),
string-concat(["xy", "x"])
]
return $a
it returns:
[ "xyx"
]
Any further ideas? Thanks.
> On Oct 6, 2015, at 3:24 PM, Ildar Absalyamov <il...@gmail.com> wrote:
>
> I believe I know why that happens. There is a rule, which enforces a type of the list, depending on the possible types of the elements.
> According to function definition "starts-with” return type is boolean, hence all nulls are stripped from the resulting list. However if you put “null” into the list explicitly that forces list elements to be of type “UNION(NULL, STRING)”, hence all null values are preserved.
> To me it seems like the solution is to should use OptionalABooleanTypeComputer for “starts-with” result type.
>
>> On Oct 6, 2015, at 15:12, Jianfeng Jia <jianfeng.jia@gmail.com <ma...@gmail.com>> wrote:
>>
>> Issue filed: https://issues.apache.org/jira/browse/ASTERIXDB-1131 <https://issues.apache.org/jira/browse/ASTERIXDB-1131> <https://issues.apache.org/jira/browse/ASTERIXDB-1131 <https://issues.apache.org/jira/browse/ASTERIXDB-1131>>
>>
>>> On Oct 6, 2015, at 3:03 PM, Mike Carey <dt...@gmail.com> wrote:
>>>
>>> Definitely not "works as designed". Sounds like a bug for sure! :-)
>>> I can imagine use cases where one would like nulls included and use cases where one would like nulls surpressed, in general - but fixing this is step one!
>>>
>>> On 10/6/15 2:52 PM, Jianfeng Jia wrote:
>>>> Hi devs,
>>>>
>>>> I hit a failed test case in which I was building a list with the elements generated from a build-in function, as below,
>>>>
>>>> for $a in [
>>>> starts-with("xyz", null),
>>>> starts-with("xy", "x")
>>>> ]
>>>> return $a
>>>>
>>>> If any of the elements is Null, it will be omitted in the returned list, e.g. the above query returns the following result:
>>>>
>>>> [ true
>>>> ]
>>>>
>>>> However if I explicitly add a null in the list, all the Nulls will be returned.
>>>> the following query:
>>>>
>>>> for $a in [
>>>> null,
>>>> starts-with("xy", null),
>>>> starts-with("xy", "x")
>>>> ]
>>>> return $a
>>>>
>>>> will return the expected result:
>>>>
>>>> [ null
>>>> , null
>>>> , true
>>>> ]
>>>> It applies for other similar functions which returns an option value.
>>>> It seems like a bug. Anyone has any ideas about this problem?
>>>>
>>>>
>>>> Best,
>>>>
>>>> Jianfeng Jia
>>>> PhD Candidate of Computer Science
>>>> University of California, Irvine
>>>>
>>>>
>>>
>>
>>
>>
>> Best,
>>
>> Jianfeng Jia
>> PhD Candidate of Computer Science
>> University of California, Irvine
>>
>
> Best regards,
> Ildar
Best,
Jianfeng Jia
PhD Candidate of Computer Science
University of California, Irvine
Re: Is it intended to skip the function-generated Null in the list?
Posted by Ildar Absalyamov <il...@gmail.com>.
I believe I know why that happens. There is a rule, which enforces a type of the list, depending on the possible types of the elements.
According to function definition "starts-with” return type is boolean, hence all nulls are stripped from the resulting list. However if you put “null” into the list explicitly that forces list elements to be of type “UNION(NULL, STRING)”, hence all null values are preserved.
To me it seems like the solution is to should use OptionalABooleanTypeComputer for “starts-with” result type.
> On Oct 6, 2015, at 15:12, Jianfeng Jia <ji...@gmail.com> wrote:
>
> Issue filed: https://issues.apache.org/jira/browse/ASTERIXDB-1131 <https://issues.apache.org/jira/browse/ASTERIXDB-1131>
>
>> On Oct 6, 2015, at 3:03 PM, Mike Carey <dt...@gmail.com> wrote:
>>
>> Definitely not "works as designed". Sounds like a bug for sure! :-)
>> I can imagine use cases where one would like nulls included and use cases where one would like nulls surpressed, in general - but fixing this is step one!
>>
>> On 10/6/15 2:52 PM, Jianfeng Jia wrote:
>>> Hi devs,
>>>
>>> I hit a failed test case in which I was building a list with the elements generated from a build-in function, as below,
>>>
>>> for $a in [
>>> starts-with("xyz", null),
>>> starts-with("xy", "x")
>>> ]
>>> return $a
>>>
>>> If any of the elements is Null, it will be omitted in the returned list, e.g. the above query returns the following result:
>>>
>>> [ true
>>> ]
>>>
>>> However if I explicitly add a null in the list, all the Nulls will be returned.
>>> the following query:
>>>
>>> for $a in [
>>> null,
>>> starts-with("xy", null),
>>> starts-with("xy", "x")
>>> ]
>>> return $a
>>>
>>> will return the expected result:
>>>
>>> [ null
>>> , null
>>> , true
>>> ]
>>> It applies for other similar functions which returns an option value.
>>> It seems like a bug. Anyone has any ideas about this problem?
>>>
>>>
>>> Best,
>>>
>>> Jianfeng Jia
>>> PhD Candidate of Computer Science
>>> University of California, Irvine
>>>
>>>
>>
>
>
>
> Best,
>
> Jianfeng Jia
> PhD Candidate of Computer Science
> University of California, Irvine
>
Best regards,
Ildar
Re: Is it intended to skip the function-generated Null in the list?
Posted by Jianfeng Jia <ji...@gmail.com>.
Issue filed: https://issues.apache.org/jira/browse/ASTERIXDB-1131 <https://issues.apache.org/jira/browse/ASTERIXDB-1131>
> On Oct 6, 2015, at 3:03 PM, Mike Carey <dt...@gmail.com> wrote:
>
> Definitely not "works as designed". Sounds like a bug for sure! :-)
> I can imagine use cases where one would like nulls included and use cases where one would like nulls surpressed, in general - but fixing this is step one!
>
> On 10/6/15 2:52 PM, Jianfeng Jia wrote:
>> Hi devs,
>>
>> I hit a failed test case in which I was building a list with the elements generated from a build-in function, as below,
>>
>> for $a in [
>> starts-with("xyz", null),
>> starts-with("xy", "x")
>> ]
>> return $a
>>
>> If any of the elements is Null, it will be omitted in the returned list, e.g. the above query returns the following result:
>>
>> [ true
>> ]
>>
>> However if I explicitly add a null in the list, all the Nulls will be returned.
>> the following query:
>>
>> for $a in [
>> null,
>> starts-with("xy", null),
>> starts-with("xy", "x")
>> ]
>> return $a
>>
>> will return the expected result:
>>
>> [ null
>> , null
>> , true
>> ]
>> It applies for other similar functions which returns an option value.
>> It seems like a bug. Anyone has any ideas about this problem?
>>
>>
>> Best,
>>
>> Jianfeng Jia
>> PhD Candidate of Computer Science
>> University of California, Irvine
>>
>>
>
Best,
Jianfeng Jia
PhD Candidate of Computer Science
University of California, Irvine