[ 
https://issues.apache.org/jira/browse/PHOENIX-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Taeyun Kim updated PHOENIX-2009:
--------------------------------
    Description: 
(Sorry if it is inappropriate to post this kind of suggestion here.)
 
I've been watching PHOENIX-477.

It's nice to support struct types, but it's not so helpful if there are already 
binary composite columns on the existing HBase tables whose format is not 
compatible with the PHOENIX-477-suggested format. And I think it's not uncommon 
since the HBase cell format is somewhat not so compact.

So, it would be nice to let the user code to handle their binary format itself.

Maybe it's related to the UDF functionality(PHOENIX-538), but more 
object-oriented. 
 
Roughly, the user code can provide the following methods:

* getDataMemberType(MemberAccessExpressionTree xtree)
* getDataMember(MemberAccessExpressionTree xtree, byte[] columnData)
* Any other methods that can be called using reflection

The first 2 methods enable the following SQL statement:

{noformat}
select userBinaryColumn from userTable where 
userBinaryColumnA.arrayFieldA[0].value < 5;
select userBinaryColumn.fieldB from userTable;
{noformat}

Here, we can select the whole varbinary value or a few 'data members' of the 
column.

And the third one can be used as follows:

{noformat}
select userBinaryColumn from userTable where 
userBinaryColumnA.getMinArrayFieldValue() < 10;
{noformat}

I think the third one has less priority to be supported.

The user code can be provided with a way similar to the UDFs. And a column can 
be bound to a user code on CREATE TABLE or ALTER TABLE statement.


  was:
(Sorry if it is inappropriate to post this kind of suggestion here.)
 
I've been watching PHOENIX-477.

It's nice to support struct types, but it's not so helpful if there are already 
binary composite columns on the existing HBase tables whose format is not 
compatible with the PHOENIX-477-suggested format. And I think it's not uncommon 
since the HBase cell format is somewhat not so compact.

So, it would be nice to let the user code to handle their binary format itself.

Maybe it's related to the UDF functionality(PHOENIX-538), but more 
object-oriented. 
 
Roughly, the user code can provide the following methods:

* getDataMemberType(MemberAccessExpressionTree xtree)
* getDataMember(MemberAccessExpressionTree xtree, byte[] columnData)
* Any other methods that can be called using reflection

The first 2 methods enable the following SQL statement:

{noformat}
select userBinaryColumn from userTable where 
userBinaryColumnA.arrayFieldA[0].value < 5;
select userBinaryColumn.fieldB from userTable;
{noformat}

Here, we can select the whole varbinary value or a few 'data members'.

And the third one can be used as follows:

{noformat}
select userBinaryColumn from userTable where 
userBinaryColumnA.getMinArrayFieldValue() < 10;
{noformat}

I think the third one has less priority to be supported.

The user code can be provided with a way similar to the UDFs. And a column can 
be bound to a user code on CREATE TABLE or ALTER TABLE statement.



> Support User-Defined Objects
> ----------------------------
>
>                 Key: PHOENIX-2009
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-2009
>             Project: Phoenix
>          Issue Type: Improvement
>            Reporter: Taeyun Kim
>            Priority: Minor
>
> (Sorry if it is inappropriate to post this kind of suggestion here.)
>  
> I've been watching PHOENIX-477.
> It's nice to support struct types, but it's not so helpful if there are 
> already binary composite columns on the existing HBase tables whose format is 
> not compatible with the PHOENIX-477-suggested format. And I think it's not 
> uncommon since the HBase cell format is somewhat not so compact.
> So, it would be nice to let the user code to handle their binary format 
> itself.
> Maybe it's related to the UDF functionality(PHOENIX-538), but more 
> object-oriented. 
>  
> Roughly, the user code can provide the following methods:
> * getDataMemberType(MemberAccessExpressionTree xtree)
> * getDataMember(MemberAccessExpressionTree xtree, byte[] columnData)
> * Any other methods that can be called using reflection
> The first 2 methods enable the following SQL statement:
> {noformat}
> select userBinaryColumn from userTable where 
> userBinaryColumnA.arrayFieldA[0].value < 5;
> select userBinaryColumn.fieldB from userTable;
> {noformat}
> Here, we can select the whole varbinary value or a few 'data members' of the 
> column.
> And the third one can be used as follows:
> {noformat}
> select userBinaryColumn from userTable where 
> userBinaryColumnA.getMinArrayFieldValue() < 10;
> {noformat}
> I think the third one has less priority to be supported.
> The user code can be provided with a way similar to the UDFs. And a column 
> can be bound to a user code on CREATE TABLE or ALTER TABLE statement.



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

Reply via email to