Junegunn Choi created HBASE-28549:
-------------------------------------

             Summary: Make shell commands support column qualifiers with colons
                 Key: HBASE-28549
                 URL: https://issues.apache.org/jira/browse/HBASE-28549
             Project: HBase
          Issue Type: Bug
          Components: shell
            Reporter: Junegunn Choi


Revisiting abandonded HBASE-13788.

h2. Problem

Shell commands do not support column qualifiers with colons (which are actually 
quite common in practice) because the part after the first colon is always 
treated as a converter expression.

This can be too restrictive because:
# Converters are only used for {{get}} and {{scan}} commands. They are not 
supported anyway for other mutating commands such as {{put}}, {{delete}}, 
{{incr}}, etc.
# Converter expression should follow a specific pattern. It should either be a 
method name of the {{Bytes}} class, or should be in {{c(CLASS).METHOD}} format. 
We ignore the part after the first colon even if it does not follow the pattern.

h2. Suggested solution

I suggest applying two approaches to make the commands support column 
qualifiers with colons.

# Do not interpret column qualifiers when using commands that don't support 
converters.
# If the part after the first colon does not follow the pattern, treat it as a 
part of the column qualifier

h2. Counterargument

Depending on how you see it, this makes the commands inconsistent in how they 
handle column qualifiers. For example, a user may want to use the same column 
expression throughout the commands.

{code}
create 't1', 'cf'

col = 'cf:cq:toLong'

# Expecting incr command to automatically ignore :toLong part
incr 't1', 'r1', col, 1

get 't1', 'r1', COLUMNS => [col]
{code}

However, if we see the converter as an option that is supported by only a few 
commands, passing it to a command that doesn't support it can be considered to 
be a user error. {{help 'put'}} or {{help 'delete'}} don't mention anything 
about converters.

h2. Alternative solution

An alternative solution would be to add a global switch that disables the 
converter interpretation altogether.




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to