[
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)
