[jira] [Created] (PHOENIX-113) Enable usage of ClientKeyValue on client-side

["James Taylor (JIRA)" <ji...@apache.org>]

James Taylor created PHOENIX-113:
------------------------------------

             Summary: Enable usage of ClientKeyValue on client-side
                 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


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)