[jira] [Comment Edited] (PHOENIX-128) Support coercion and descending sort order for ARRAY

["James Taylor (JIRA)" <ji...@apache.org>]

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

James Taylor edited comment on PHOENIX-128 at 3/12/14 5:28 AM:
---------------------------------------------------------------

I think the early exit condition still needs some modifications. You basically can exit early if you know that the bytes you'll generate would already match the existing bytes. Note that value may be null, as there are some cases in which we don't have a value, so the only thing you should count on is ptr pointing to a set of bytes. Some instead of this:
{code}
        if (ptr.getLength() == 0 || value == null) { 
            return; 
        }
        if(maxLength == null && actualType.isBytesComparableWith(desiredType) && actualModifer == expectedModifier) {
            return;
        }
        if (Objects.equal(maxLength, desiredMaxLength)) { 
            return; 
        }
{code}

How about this?
{code}
        if (ptr.getLength() == 0) { // a zero length ptr means null which will not be coerced to anything different
            return; 
        }
        // If the length is not changing (or there is no fixed length) and
        // the existing type and the new type will serialize to the same bytes and
        // the sort order is not changing, then ptr already points to the correct
        // set of bytes and there's nothing to do
        if (   ( Objects.equal(maxLength, desiredMaxLength) || maxLength == null )
         &&  actualType.isBytesComparableWith(desiredType)
         && actualModifer == expectedModifier) {
            return;
        }
        if (Objects.equal(maxLength, desiredMaxLength)) { 
            return; 
        }
{code}



was (Author: jamestaylor):
I think the early exit condition still needs some modifications. You basically can exit early if you know that the bytes you'll generate would already match the existing bytes. Note that value may be null, as there are some cases in which we don't have a value, so the only thing you should count on is ptr pointing to a set of bytes. Some instead of this:
        if (ptr.getLength() == 0 || value == null) { 
            return; 
        }
        if(maxLength == null && actualType.isBytesComparableWith(desiredType) && actualModifer == expectedModifier) {
            return;
        }
        if (Objects.equal(maxLength, desiredMaxLength)) { 
            return; 
        }
{code}

How about this?
{code}
        if (ptr.getLength() == 0) { // a zero length ptr means null which will not be coerced to anything different
            return; 
        }
        // If the length is not changing (or there is no fixed length) and
        // the existing type and the new type will serialize to the same bytes and
        // the sort order is not changing, then ptr already points to the correct
        // set of bytes and there's nothing to do
        if (   ( Objects.equal(maxLength, desiredMaxLength) || maxLength == null )
         &&  actualType.isBytesComparableWith(desiredType)
         && actualModifer == expectedModifier) {
            return;
        }
        if (Objects.equal(maxLength, desiredMaxLength)) { 
            return; 
        }
{code}


> Support coercion and descending sort order for ARRAY
> ----------------------------------------------------
>
>                 Key: PHOENIX-128
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-128
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>            Assignee: ramkrishna.s.vasudevan
>             Fix For: 3.0.0
>
>         Attachments: Phoenix-128_1.patch, Phoenix-128_2.patch
>
>
> Now that our ARRAY types may be used in the primary key, we need to support descending sort order (i.e. inverting the bits). There are also holes in the support for coerce, as it's legitimate to coerce an array of BIGINT to an array of INTEGER for example.
> This can all be handled pretty easily in the PArrayDataType.coerceBytes() method.



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