Larry McCay created KNOX-2022:
---------------------------------
Summary: KnoxShellTable - Introduce Schema for DataTypes of Columns
Key: KNOX-2022
URL: https://issues.apache.org/jira/browse/KNOX-2022
Project: Apache Knox
Issue Type: Improvement
Components: KnoxShell
Reporter: Larry McCay
Fix For: 1.4.0
The initial motivation for KnoxShellTable was for render tabular data to the
console for representing SQL responses from KnoxLine as a simple SQL client.
This didn't immediately require heterogeneous datatypes across the table.
Therefore, everything is of type String in the underlying structures of the
table.
As we extend the usecases and features for this class, the need to convert the
underlying type to other types for operations such as compareTo or for sorting
or in the future for supporting calculations, etc has emerged and may be
affecting the API design or at least the implementation.
This JIRA represents a need to revisit either the underlying structures, adding
schema as optional metadata to the cols or both. If the conversion to and from
Strings as the underlying type means that we need to make design or
implementation compromises that are understandable then we may want to lean
toward refactoring the underlying structures.
I do want to retain the simplicity of use however and wouldn't like to see
mandatory schema as a burden for simple usecases. The fluid API design should
also remain as simple and natural as possible with use of primitive types for
operations. How this is handled within the implementation shouldn't affect the
interface.
For instance:
table.filter().name("price").greaterThan(100000.00d)
The above should be able to leverage Java's autoboxing to convert the primitive
double param into a Double. Internally, we can then do whatever type of
conversions are necessary based on the schema introduced here. If we can do it
without conversion that would be even better.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)