[jira] [Commented] (KNOX-2022) KnoxShellTable - Introduce Schema for DataTypes of Columns

["ASF subversion and git services (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KNOX-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16939736#comment-16939736 ] 

ASF subversion and git services commented on KNOX-2022:
-------------------------------------------------------

Commit 8e7e9d93bceb09fb77fe0bb77fdf01ab5ef6dbf7 in knox's branch refs/heads/master from Sandor Molnar
[ https://gitbox.apache.org/repos/asf?p=knox.git;h=8e7e9d9 ]

KNOX-2022 - Splitting up KnoxShellTable and do minor cleanup


> 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: 50m
>  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)