[
https://issues.apache.org/jira/browse/KNOX-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16939737#comment-16939737
]
ASF subversion and git services commented on KNOX-2022:
-------------------------------------------------------
Commit 5c2c7a727d8e88e47ce1d14cb803c9a9f4473c29 in knox's branch
refs/heads/master from Sandor Molnar
[ https://gitbox.apache.org/repos/asf?p=knox.git;h=5c2c7a7 ]
KNOX-2022 - KnoxShellTable contains Comparables instead of Strings
Closes #157
Signed-off-by: Kevin Risden <[email protected]>
> 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
> Assignee: Sandor Molnar
> Priority: Major
> Fix For: 1.4.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> 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)
