[ 
https://issues.apache.org/jira/browse/PHOENIX-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14512267#comment-14512267
 ] 

ASF GitHub Bot commented on PHOENIX-538:
----------------------------------------

Github user samarthjain commented on a diff in the pull request:

    https://github.com/apache/phoenix/pull/77#discussion_r29098096
  
    --- Diff: 
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java
 ---
    @@ -700,6 +1007,29 @@ private PTable loadTable(RegionCoprocessorEnvironment 
env, byte[] key,
             return null;
         }
     
    +    private PFunction loadFunction(RegionCoprocessorEnvironment env, 
byte[] key,
    +            ImmutableBytesPtr cacheKey, long clientTimeStamp, long 
asOfTimeStamp)
    +            throws IOException, SQLException {
    +            HRegion region = env.getRegion();
    +            Cache<ImmutableBytesPtr,PMetaDataEntity> metaDataCache = 
GlobalCache.getInstance(this.env).getMetaDataCache();
    +            PFunction function = 
(PFunction)metaDataCache.getIfPresent(cacheKey);
    +            // We always cache the latest version - fault in if not in 
cache
    +            if (function != null) {
    +                return function;
    +            }
    +            ArrayList<byte[]> arrayList = new ArrayList<byte[]>(1);
    +            arrayList.add(key);
    +            List<PFunction> functions = buildFunctions(arrayList, region, 
asOfTimeStamp);
    +            if(functions != null) return functions.get(0);
    +            // if not found then check if newer table already exists and 
add delete marker for timestamp
    --- End diff --
    
    newer function?


> Support UDFs
> ------------
>
>                 Key: PHOENIX-538
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-538
>             Project: Phoenix
>          Issue Type: Task
>            Reporter: James Taylor
>            Assignee: Rajeshbabu Chintaguntla
>             Fix For: 5.0.0, 4.4.0
>
>         Attachments: PHOENIX-538-wip.patch, PHOENIX-538_v1.patch, 
> PHOENIX-538_v2.patch, PHOENIX-538_v3.patch, PHOENIX-538_v4.patch, 
> PHOENIX-538_v5.patch, PHOENIX-538_v6.patch, PHOENIX-538_v6.patch
>
>
> Phoenix allows built-in functions to be added (as described 
> [here](http://phoenix-hbase.blogspot.com/2013/04/how-to-add-your-own-built-in-function.html))
>  with the restriction that they must be in the phoenix jar. We should improve 
> on this and allow folks to declare new functions through a CREATE FUNCTION 
> command like this:
>       CREATE FUNCTION mdHash(anytype)
>       RETURNS binary(16)
>       LOCATION 'hdfs://path-to-my-jar' 'com.me.MDHashFunction'
> Since HBase supports loading jars dynamically, this would not be too 
> difficult. The function implementation class would be required to extend our 
> ScalarFunction base class. Here's how I could see it being implemented:
> * modify the phoenix grammar to support the new CREATE FUNCTION syntax
> * create a new UTFParseNode class to capture the parse state
> * add a new method to the MetaDataProtocol interface
> * add a new method in ConnectionQueryServices to invoke the MetaDataProtocol 
> method
> * add a new method in MetaDataClient to invoke the ConnectionQueryServices 
> method
> * persist functions in a new "SYSTEM.FUNCTION" table
> * add a new client-side representation to cache functions called PFunction
> * modify ColumnResolver to dynamically resolve a function in the same way we 
> dynamically resolve and load a table
> * create and register a new ExpressionType called UDFExpression
> * at parse time, check for the function name in the built in list first (as 
> is currently done), and if not found in the PFunction cache. If not found 
> there, then use the new UDFExpression as a placeholder and have the 
> ColumnResolver attempt to resolve it at compile time and throw an error if 
> unsuccessful.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to