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

James Taylor commented on PHOENIX-128:
--------------------------------------

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)

Reply via email to