You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@asterixdb.apache.org by Till Westmann <ti...@apache.org> on 2015/12/09 20:59:03 UTC
Handling of untyped content
Hi,
Ildar has filed ASTERIXDB-1219 in response to a number of issues with
built-in functions that do not handle untyped parameters well. While I
see the problem, I think that the solution should not be to add
conditional code to each implementation.
Instead, I think that we should have functions that guarantee the
correct input type or type conversion (or throw an error) and rely on
the rewriter to ensure that these “enforcing” functions are placed
into the plan only if the type check cannot determine that the correct
input type is provided.
That way the enforcement code would be only in the plan when needed.
Thoughts?
Cheers,
Till
[1] https://issues.apache.org/jira/browse/ASTERIXDB-1219
Re: Handling of untyped content
Posted by Chris Hillery <ch...@hillery.land>.
+1 from me.
Ceej
On Wed, Dec 9, 2015 at 11:59 AM, Till Westmann <ti...@apache.org> wrote:
> Hi,
>
> Ildar has filed ASTERIXDB-1219 in response to a number of issues with
> built-in functions that do not handle untyped parameters well. While I see
> the problem, I think that the solution should not be to add conditional
> code to each implementation.
> Instead, I think that we should have functions that guarantee the correct
> input type or type conversion (or throw an error) and rely on the rewriter
> to ensure that these “enforcing” functions are placed into the plan only if
> the type check cannot determine that the correct input type is provided.
> That way the enforcement code would be only in the plan when needed.
>
> Thoughts?
>
> Cheers,
> Till
>
> [1] https://issues.apache.org/jira/browse/ASTERIXDB-1219
>
Re: Handling of untyped content
Posted by Till Westmann <ti...@apache.org>.
No, I don’t think so. We’d have one enforcer function for each type
that we can have for a parameter in a function signature. And all type
checking would be removed from the individual functions. The
translator/rewriter would then ensure that all parameters go though an
enforcer function, unless the type checker can statically determine that
no type check is necessary.
Does this make sense?
Cheers,
Till
On 9 Dec 2015, at 12:37, Ildar Absalyamov wrote:
> That will still mean that we’ll have to double the number of
> functions by creating “enforced” version of each function, right?
> In either case it will introduce additional code. However in the
> former approach it is going to be located in only type computers. In
> ideal world all those type computers should be auto generated, since
> it is a bunch of boilerplate code, without any specifics (except for
> the type of course). In that case having additional checks there will
> be tolerable.
>
>> On Dec 9, 2015, at 11:59, Till Westmann <ti...@apache.org> wrote:
>>
>> Hi,
>>
>> Ildar has filed ASTERIXDB-1219 in response to a number of issues with
>> built-in functions that do not handle untyped parameters well. While
>> I see the problem, I think that the solution should not be to add
>> conditional code to each implementation.
>> Instead, I think that we should have functions that guarantee the
>> correct input type or type conversion (or throw an error) and rely on
>> the rewriter to ensure that these “enforcing” functions are
>> placed into the plan only if the type check cannot determine that the
>> correct input type is provided.
>> That way the enforcement code would be only in the plan when needed.
>>
>> Thoughts?
>>
>> Cheers,
>> Till
>>
>> [1] https://issues.apache.org/jira/browse/ASTERIXDB-1219
>
> Best regards,
> Ildar
Re: Handling of untyped content
Posted by Ildar Absalyamov <il...@gmail.com>.
That will still mean that we’ll have to double the number of functions by creating “enforced” version of each function, right?
In either case it will introduce additional code. However in the former approach it is going to be located in only type computers. In ideal world all those type computers should be auto generated, since it is a bunch of boilerplate code, without any specifics (except for the type of course). In that case having additional checks there will be tolerable.
> On Dec 9, 2015, at 11:59, Till Westmann <ti...@apache.org> wrote:
>
> Hi,
>
> Ildar has filed ASTERIXDB-1219 in response to a number of issues with built-in functions that do not handle untyped parameters well. While I see the problem, I think that the solution should not be to add conditional code to each implementation.
> Instead, I think that we should have functions that guarantee the correct input type or type conversion (or throw an error) and rely on the rewriter to ensure that these “enforcing” functions are placed into the plan only if the type check cannot determine that the correct input type is provided.
> That way the enforcement code would be only in the plan when needed.
>
> Thoughts?
>
> Cheers,
> Till
>
> [1] https://issues.apache.org/jira/browse/ASTERIXDB-1219
Best regards,
Ildar
Re: Handling of untyped content
Posted by Yingyi Bu <bu...@gmail.com>.
+1!
Best,
Yingyi
On Wed, Dec 9, 2015 at 11:59 AM, Till Westmann <ti...@apache.org> wrote:
> Hi,
>
> Ildar has filed ASTERIXDB-1219 in response to a number of issues with
> built-in functions that do not handle untyped parameters well. While I see
> the problem, I think that the solution should not be to add conditional
> code to each implementation.
> Instead, I think that we should have functions that guarantee the correct
> input type or type conversion (or throw an error) and rely on the rewriter
> to ensure that these “enforcing” functions are placed into the plan only if
> the type check cannot determine that the correct input type is provided.
> That way the enforcement code would be only in the plan when needed.
>
> Thoughts?
>
> Cheers,
> Till
>
> [1] https://issues.apache.org/jira/browse/ASTERIXDB-1219
>
Re: Handling of untyped content
Posted by Mike Carey <dt...@gmail.com>.
Yeah, I was wondering about function metadata that could say something
like "skip me and output the appropriate unknown if either of my inputs
are unknown". (It wouldn't be useable by things like AND or OR or other
special-cased functions.) But maybe that wouldn't save enough work....
On 12/9/15 10:25 PM, Till Westmann wrote:
> On 9 Dec 2015, at 13:06, Mike Carey wrote:
>
>> +1
>>
>> Q: Do we need (or want) something similarly generic for null/missing
>> value handling by functions?
>
> I think that’s a little trickier, as we’d probably need something that
> wraps the function implementation.
> The null/missing behavior usually does something to the output of the
> function based on the fact that one of the inputs is null or missing.
> Maybe some code generation would be helpful here :)
>
> Cheers,
> Till
>
>> On 12/9/15 11:59 AM, Till Westmann wrote:
>>> Hi,
>>>
>>> Ildar has filed ASTERIXDB-1219 in response to a number of issues
>>> with built-in functions that do not handle untyped parameters well.
>>> While I see the problem, I think that the solution should not be to
>>> add conditional code to each implementation.
>>> Instead, I think that we should have functions that guarantee the
>>> correct input type or type conversion (or throw an error) and rely
>>> on the rewriter to ensure that these “enforcing” functions are
>>> placed into the plan only if the type check cannot determine that
>>> the correct input type is provided.
>>> That way the enforcement code would be only in the plan when needed.
>>>
>>> Thoughts?
>>>
>>> Cheers,
>>> Till
>>>
>>> [1] https://issues.apache.org/jira/browse/ASTERIXDB-1219
Re: Handling of untyped content
Posted by Till Westmann <ti...@apache.org>.
On 9 Dec 2015, at 13:06, Mike Carey wrote:
> +1
>
> Q: Do we need (or want) something similarly generic for null/missing
> value handling by functions?
I think that’s a little trickier, as we’d probably need something
that wraps the function implementation.
The null/missing behavior usually does something to the output of the
function based on the fact that one of the inputs is null or missing.
Maybe some code generation would be helpful here :)
Cheers,
Till
> On 12/9/15 11:59 AM, Till Westmann wrote:
>> Hi,
>>
>> Ildar has filed ASTERIXDB-1219 in response to a number of issues with
>> built-in functions that do not handle untyped parameters well. While
>> I see the problem, I think that the solution should not be to add
>> conditional code to each implementation.
>> Instead, I think that we should have functions that guarantee the
>> correct input type or type conversion (or throw an error) and rely on
>> the rewriter to ensure that these “enforcing” functions are
>> placed into the plan only if the type check cannot determine that the
>> correct input type is provided.
>> That way the enforcement code would be only in the plan when needed.
>>
>> Thoughts?
>>
>> Cheers,
>> Till
>>
>> [1] https://issues.apache.org/jira/browse/ASTERIXDB-1219
Re: Handling of untyped content
Posted by Mike Carey <dt...@gmail.com>.
+1
Q: Do we need (or want) something similarly generic for null/missing
value handling by functions?
On 12/9/15 11:59 AM, Till Westmann wrote:
> Hi,
>
> Ildar has filed ASTERIXDB-1219 in response to a number of issues with
> built-in functions that do not handle untyped parameters well. While I
> see the problem, I think that the solution should not be to add
> conditional code to each implementation.
> Instead, I think that we should have functions that guarantee the
> correct input type or type conversion (or throw an error) and rely on
> the rewriter to ensure that these “enforcing” functions are placed
> into the plan only if the type check cannot determine that the correct
> input type is provided.
> That way the enforcement code would be only in the plan when needed.
>
> Thoughts?
>
> Cheers,
> Till
>
> [1] https://issues.apache.org/jira/browse/ASTERIXDB-1219