[jira] [Comment Edited] (PHOENIX-1055) Add support for the built-in functions HEX, OCT, and BIN

["Kyle Buzsaki (JIRA)" <ji...@apache.org>]

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

Kyle Buzsaki edited comment on PHOENIX-1055 at 7/10/14 8:53 PM:
----------------------------------------------------------------

Attached patch of new EncodeFormat implementation

I changed it so that EncodeFormats have encoder and decoder members that may be null to indicate unsupported behavior. 

Some of the unit tests for DecodeFunction aren't passing at the moment so I'll have to fix those, but I wanted to put the work out there for feedback.

Things to consider:
* There still isn't an EncodeFormat that doesn't support encoding, so what should we do about the EncodeFunctionIT test that checks for unsupported encodings? We could add an UNSUPPORTED_FORMAT element to the enum with both a null encoder and null decoder specifically for the test and use that, but that seems pretty gross. 
* With this new format it may make sense to move the Base62Encoder util class logic into the EncodeFormat class, perhaps as a static inner class. This would help to eliminate the anonymous inner class currently used for the BASE62 constructor and make the code more readable.
* Why does the DECODE function return a VARBINARY while the ENCODE function takes a LONG? I would expect them to be inverses of each other. Is there a way to convert a VARBINARY to a LONG? A simple cast doesn't seem to work.


was (Author: kbuzsaki):
Attached patch of new EncodeFormat implementation

I changed it so that EncodeFormats have encoder and decoder members that may be null to indicate unsupported behavior. 

Some of the unit tests for DecodeFunction aren't passing at the moment so I'll have to fix those, but I wanted to put the work out there for feedback.

Things to consider:
* There still isn't an EncodeFormat that doesn't support encoding, so what should we do about the EncodeFunctionIT test that checks for unsupported encodings? We could add an UNSUPPORTED_FORMAT element to the enum with both a null encoder and null decoder specifically for the test and use that, but that seems pretty gross. 
* With this new format it may make sense to move the Base62Encoder util class logic into the EncodeFormat class, perhaps as a static inner class. This would help to eliminate the anonymous inner class currently used for the BASE62 constructor and make the code more readable.

> Add support for the built-in functions HEX, OCT, and BIN 
> ---------------------------------------------------------
>
>                 Key: PHOENIX-1055
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-1055
>             Project: Phoenix
>          Issue Type: New Feature
>            Reporter: Kyle Buzsaki
>         Attachments: PHOENIX-1055.patch, PHOENIX-1055_2.patch, PHOENIX-1055_3.patch
>
>
> Add built-in functions to produce hexadecimal, octal, and binary string representations of numeric values.
> Example Function Specification:
> http://dev.mysql.com/doc/refman/5.0/en/string-functions.html#function_hex
> http://dev.mysql.com/doc/refman/5.0/en/string-functions.html#function_oct
> http://dev.mysql.com/doc/refman/5.0/en/string-functions.html#function_bin



--
This message was sent by Atlassian JIRA
(v6.2#6252)