[
https://issues.apache.org/jira/browse/PIG-969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olga Natkovich updated PIG-969:
-------------------------------
Fix Version/s: 0.9.0
Description:
This issue is discussed in
http://www.mail-archive.com/pig-u...@hadoop.apache.org/msg00524.html . I am
able to reproduce the issue. While it is easy to fix the udf, it can take a lot
of time to figure out the problem (until they find this email conversation!).
The root cause is that when getArgToFuncMapping is defined in the udf , the
FuncSpec returned by the method replaces one set by define statement . The
constructor arguments get lost. We can handle this in following ways -
1. Preserve the constructor arguments, and use it with the class name of the
matching FuncSpec from getArgToFuncMapping .
2. Give an error if constructor paramerters are given for a udf which has
FuncSpecs returned from getArgToFuncMapping .
The problem with approach 1 is that we are letting the user define the
FuncSpec , so user could have defined a FuncSpec with constructor (though they
don't have a valid reason to do so.). It is also possible the the constructor
of the different class that matched might not support same constructor
parameters. The use of this function outside builtin udfs are also probably not
common.
With option 2, we are telling the user that this is not a supported use case,
and user can easily change the udf to fix the issue, or use the udf which would
have matched given parameters (which unlikely to have the getArgToFuncMapping
method defined).
I am proposing that we go with option 2 .
was:
This issue is discussed in
http://www.mail-archive.com/pig-u...@hadoop.apache.org/msg00524.html . I am
able to reproduce the issue. While it is easy to fix the udf, it can take a lot
of time to figure out the problem (until they find this email conversation!).
The root cause is that when getArgToFuncMapping is defined in the udf , the
FuncSpec returned by the method replaces one set by define statement . The
constructor arguments get lost. We can handle this in following ways -
1. Preserve the constructor arguments, and use it with the class name of the
matching FuncSpec from getArgToFuncMapping .
2. Give an error if constructor paramerters are given for a udf which has
FuncSpecs returned from getArgToFuncMapping .
The problem with approach 1 is that we are letting the user define the
FuncSpec , so user could have defined a FuncSpec with constructor (though they
don't have a valid reason to do so.). It is also possible the the constructor
of the different class that matched might not support same constructor
parameters. The use of this function outside builtin udfs are also probably not
common.
With option 2, we are telling the user that this is not a supported use case,
and user can easily change the udf to fix the issue, or use the udf which would
have matched given parameters (which unlikely to have the getArgToFuncMapping
method defined).
I am proposing that we go with option 2 .
> Default constructor of UDF gets called for UDF with parameterised constructor
> , if the udf has a getArgToFuncMapping function defined
> -------------------------------------------------------------------------------------------------------------------------------------
>
> Key: PIG-969
> URL: https://issues.apache.org/jira/browse/PIG-969
> Project: Pig
> Issue Type: Bug
> Components: impl
> Reporter: Thejas M Nair
> Fix For: 0.9.0
>
>
> This issue is discussed in
> http://www.mail-archive.com/pig-u...@hadoop.apache.org/msg00524.html . I am
> able to reproduce the issue. While it is easy to fix the udf, it can take a
> lot of time to figure out the problem (until they find this email
> conversation!).
> The root cause is that when getArgToFuncMapping is defined in the udf , the
> FuncSpec returned by the method replaces one set by define statement . The
> constructor arguments get lost. We can handle this in following ways -
> 1. Preserve the constructor arguments, and use it with the class name of the
> matching FuncSpec from getArgToFuncMapping .
> 2. Give an error if constructor paramerters are given for a udf which has
> FuncSpecs returned from getArgToFuncMapping .
> The problem with approach 1 is that we are letting the user define the
> FuncSpec , so user could have defined a FuncSpec with constructor (though
> they don't have a valid reason to do so.). It is also possible the the
> constructor of the different class that matched might not support same
> constructor parameters. The use of this function outside builtin udfs are
> also probably not common.
> With option 2, we are telling the user that this is not a supported use case,
> and user can easily change the udf to fix the issue, or use the udf which
> would have matched given parameters (which unlikely to have the
> getArgToFuncMapping method defined).
> I am proposing that we go with option 2 .
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
