[
https://issues.apache.org/jira/browse/PHOENIX-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Yates updated PHOENIX-113:
--------------------------------
Attachment: phoenix-113-sketch.txt
Attaching a sketch of how one might go about implementing an IndexWriter to
solve this, in the theme of Option (2) and (3) described above.
Then we just need to switch the configuration for phoenix to use that writer,
when implemented, and we should be good.
> 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)
