NIFI-1895 for 0.x #542
NIFI-1895 for 0.x #542
Conversation
The operator will now inspect the node value to determine type and convert as such. Numeric integral - Long (assumes widest type) Numeric not integral - Double (assumes widest type) Logical - Boolean everything else (including current Complex Type logic) - String Values that represent the row key continue to be implictly treated as Strings by the processor Removed depenency on HBase utility Bytes class from the PutHBaseJSON processor. Convenience methods to encode to byte array are now wrapped by the appropriate HBaseClientService instance.
…o store the values
| protected static final String BYTES_ENCODING_VALUE = "Bytes"; | ||
|
|
||
| protected static final AllowableValue FIELD_ENCODING_STRING = new AllowableValue(STRING_ENCODING_VALUE, STRING_ENCODING_VALUE, | ||
| "Stores the value of each field as a UTF-8 String."); |
There was a problem hiding this comment.
Should the charset be selectable or will it always be UTF-8?
There was a problem hiding this comment.
Secondly, will users configuring this processor know what a "String" is (aka. is it a concept that is used regularly when configuring HBase)?
There was a problem hiding this comment.
The existing PutHBase always produced UTF-8 so I think we are ok there.
I couldn't come up with great names for these choices so I would be open to something else if there was a better name, but I think if people read the descriptions of the values it will be clear.
There was a problem hiding this comment.
That works for me.
That's fair, if questions come in to the mailing list asking to clarify then we can address the description.
|
Good point, thanks @bbende, I hadn't thought to leave a backward compatibility feature in there. |
|
Specifically looking at Bryan's commit: I looked through the code and built locally (since travis failed for un-related issues) and it looks good. +1 |
…o store the values This closes #542. Signed-off-by: Bryan Bende <bbende@apache.org>
3 participants
This pull request contains @rtempleton 's work from PR 513, but rebased for the 0.x branch.
In addition, there is another commit by me which adds a new property to PutHBaseJSON allowing the user to specify how to store the values. The reason for this is that we can't change the behavior for existing users who may want the processor to continue working how it was. This change makes the default behavior the same as previous versions, but allows the user to enable the change Ryan made.