[
https://issues.apache.org/jira/browse/PHOENIX-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13921943#comment-13921943
]
James Taylor commented on PHOENIX-113:
--------------------------------------
>From [~jesse_yates]:
bq. I'd rather do that one layer up as I proposed in the PhoenixWriterCommiter,
it helps separate concerns for cases where users want to use the indexing but
don't want all the rest of the phoenix stuff.
The KeyValueBuilder stuff has no dependencies on Phoenix. I'll move it into the
index.util package. When you have more time, please feel free to rework it.
> Enable usage of ClientKeyValue on for indexing on server
> --------------------------------------------------------
>
> Key: PHOENIX-113
> URL: https://issues.apache.org/jira/browse/PHOENIX-113
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 3.0.0
> Reporter: James Taylor
> Fix For: 3.0.0
>
> Attachments: phoenix-113-sketch.txt
>
>
> Modify code to go through KeyValueBuilder where necessary. Adding abstraction
> for having different KVComparator on each KeyValueBuilder impl.
> Still doesn't work on the server-side due to memstore needing a backing
> buffer for the KeyValue.
> According to [~jesse_yates], the options are:
> 1. Update the ClientKeyValues on the way out via a new hook in the codec,
> e.g. "preWriteToIndexTable(List<Mutation>, byte[] indexTable)",
> Wrap all the clientkvs in something like an ImmutableClientKeyValue that does
> the right thing for getBuffer, getOffset, etc, but without doing all the
> copying. This may be easier to just do as modifications to ClientKeyValue,
> but seems easier to start as a new class first
> 2. Automatically check all the mutations being written in the
> ParallelIndexWriter for being clientKeyvalues
> A bit more painful than the above, since you could short circuit there, but
> easier in terms of code complexity
> 3. Check to see if the write is going to a local region and then transform
> the ClientKeyValues when necessary
> Most difficult as it reaches down into the guts of the coprocessor logic for
> determining region location. Unfortunately, it is already being done by the
> CoprocessorHConnection, but we would need to recreate it for us before it
> hits the HTable.
> You could do it by creating a CoprocessorHConnection and then wrapping that
> in a ClientKeyValueCheckingHConnection and then passing that into the
> constructor for HTable creation.
> This is even more onerous as that constructor is only available on an HTable
> directly, not via the CoprocessorEnvironment, meaning we have to manually
> close tables. We have pretty good exception wrapping, so its not terrible to
> implement, but still a pain to do.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
