[
https://issues.apache.org/jira/browse/PHOENIX-5550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16966289#comment-16966289
]
Lars Hofhansl edited comment on PHOENIX-5550 at 11/3/19 10:49 PM:
------------------------------------------------------------------
The same problem occurs when we create an index from an 4.14 or before client.
Looks like what's happening is that even though we only use smallint index
values, we nonetheless want to store it as a long in the index row keys at
least for newly created indexes.
We could bring back the bigger the fixes I had in PHOENIX-5486 (namely the part
where we actually adjust the values of the sequence, if it has been created
newly), or we could (somehow) figure out in the IndexMaintainer that this
index's build needs to store the value as long. Both are messy.
The relevant code it here:
{code:java}
public static IndexMaintainer fromProto(ServerCachingProtos.IndexMaintainer
proto, RowKeySchema dataTableRowKeySchema, boolean isDataTableSalted) throws
IOException {
IndexMaintainer maintainer = new IndexMaintainer(dataTableRowKeySchema,
isDataTableSalted);
maintainer.nIndexSaltBuckets = proto.getSaltBuckets();
maintainer.isMultiTenant = proto.getIsMultiTenant();
maintainer.viewIndexId = proto.hasViewIndexId() ?
proto.getViewIndexId().toByteArray() : null;
maintainer.viewIndexIdType = proto.hasViewIndexIdType()
? PDataType.fromTypeId(proto.getViewIndexIdType())
: MetaDataUtil.getLegacyViewIndexIdDataType(); {code}
Called from {{UngroupedAggregateRegionObserver.doPostScannerOpen}} when
{{scan.getAttribute(LOCAL_INDEX_BUILD_PROTO)}} is set.
This should be driven by the actual index, not by what the client passes as
type. If we had the server-version at which the index was created we could it
that way for example.
I'll bring up again the possibility of reverting the viewIndexId change to
long. [~gjacoby] .
was (Author: lhofhansl):
The same problem occurs when we create an index from an 4.14 or before client.
Looks like what's happening is that even though we only use smallint index
values, we nonetheless want to store it as a long in the index row keys at
least for newly created indexes.
We could bring back the bigger the fixes I had in PHOENIX-5486 (namely the part
where we actually adjust the values of the sequence, if it has been created
newly), or we could (somehow) figure out in the IndexMaintainer that this
index's build needs to store the value as long. Both are messy.
The relevant code it here:
{code:java}
public static IndexMaintainer fromProto(ServerCachingProtos.IndexMaintainer
proto, RowKeySchema dataTableRowKeySchema, boolean isDataTableSalted) throws
IOException {
IndexMaintainer maintainer = new IndexMaintainer(dataTableRowKeySchema,
isDataTableSalted);
maintainer.nIndexSaltBuckets = proto.getSaltBuckets();
maintainer.isMultiTenant = proto.getIsMultiTenant();
maintainer.viewIndexId = proto.hasViewIndexId() ?
proto.getViewIndexId().toByteArray() : null;
maintainer.viewIndexIdType = proto.hasViewIndexIdType()
? PDataType.fromTypeId(proto.getViewIndexIdType())
: MetaDataUtil.getLegacyViewIndexIdDataType(); {code}
This should be driven by the actual index, not by what the client passes as
type. If we had the server-version at which the index was created we could it
that way for example.
I'll bring up again the possibility of reverting the viewIndexId change to
long. [~gjacoby] .
> Scan after local index creation on table having data giving wrong results
> when long view index id disabled
> ----------------------------------------------------------------------------------------------------------
>
> Key: PHOENIX-5550
> URL: https://issues.apache.org/jira/browse/PHOENIX-5550
> Project: Phoenix
> Issue Type: Bug
> Reporter: Rajeshbabu Chintaguntla
> Assignee: Rajeshbabu Chintaguntla
> Priority: Blocker
> Fix For: 4.15.0, 5.1.0
>
> Attachments: PHOENIX-5550.patch
>
>
> After PHOENIX-3547 and PHOENIX-5104 querying after local index creation on
> the table having data is failing because of the view index id type mismatches.
> The client is sending the SMALLINT as view index id data type.
> {noformat}
> private PDataType getViewIndexDataType() throws SQLException {
> boolean supportsLongViewIndexId =
> connection.getQueryServices().getProps().getBoolean(
> QueryServices.LONG_VIEW_INDEX_ENABLED_ATTRIB,
>
> QueryServicesOptions.DEFAULT_LONG_VIEW_INDEX_ENABLED);
> return supportsLongViewIndexId ?
> MetaDataUtil.getViewIndexIdDataType() :
> MetaDataUtil.getLegacyViewIndexIdDataType();
> }
> {noformat}
> But in the create index api in endpoint impl is considering LONG as view
> index id data type.
> {noformat}
> PDataType dataType =
> MetaDataUtil.getViewIndexIdDataType();
> Object val = dataType.toObject(seqValue,
> PLong.INSTANCE);
> byte[] bytes = new byte[dataType.getByteSize() + 1];
> dataType.toBytes(val, bytes, 0);
> Cell indexIdCell =
>
> PhoenixKeyValueUtil.newKeyValue(cell.getRowArray(),
> cell.getRowOffset(), cell.getRowLength(),
> cell.getFamilyArray(),
> cell.getFamilyOffset(),
> cell.getFamilyLength(),
> VIEW_INDEX_ID_BYTES, 0,
> VIEW_INDEX_ID_BYTES.length,
> cell.getTimestamp(), bytes, 0,
> bytes.length, cell.getType());
> {noformat}
> {noformat}
> if (indexId != null) {
> builder.setViewIndexId(indexId);
> builder.setViewIndexIdType(PLong.INSTANCE.getSqlType());
> }
> {noformat}
>
> Most of the local index tests failing If we set false value to the following
> configuration.
> <property>
> <!--
> We have some hardcoded viewIndex ids in the IT tests which assumes
> viewIndexId is of type Long.
> However the default viewIndexId type is set to "short" by default until
> we upgrade all clients to support
> long viewIndex ids.
> -->
> <name>phoenix.index.longViewIndex.enabled</name>
> <value>false</value>
> </property>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
