[ 
https://issues.apache.org/jira/browse/KNOX-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sandor Molnar reassigned KNOX-2022:
-----------------------------------

    Assignee: Sandor Molnar

> 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
>
>
> 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)

Reply via email to