[
https://issues.apache.org/jira/browse/DRILL-7479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16995214#comment-16995214
]
ASF GitHub Bot commented on DRILL-7479:
---------------------------------------
paul-rogers commented on issue #1923: DRILL-7479: Partial fixes for metadata
parameterized type issues
URL: https://github.com/apache/drill/pull/1923#issuecomment-565238765
Another commit to fix the remaining warnings in metastore.
Just to summarize based on what I've seen, there are two use cases:
* Generic: Example: take two columns, get their min values generically,
combine them generically. Compile-time typing is a hindrance here; we need
run-time typing.
* Specific: compute or obtain a specific value of a specific type. The NDV,
say, to be used in estimating selectivity.
It is easy to go from specific to generic:
```
int foo = ...;
metadata.setValue(foo);
...
public void setValue(Object value) {
...
```
If is harder to go the other way. If we know the value is an `int`:
```
int foo = metadata.getInt();
// Or, less ideally:
assert metadata.getType() == MinorType.INT;
int foo = (Int) metadata.getValue();
```
Here `getInt()` just does in a method what the second example does inline.
To be type aware for all types:
```
switch(metadata.getType()) {
case INT:
int intFoo = (Int) metadata.getValue();
...
case VARCHAR:
String strFoo = (String) metadata.getValue();
...
```
The above is true if we introduce, say a `ValueHolder<T>` that holds a value
of type T. Instead of casting the value, we'd cast the value holder. There is
no escaping the issue.
Point is: we need to understand the use cases so we can more precisely
refine the metadata data model.
Some example:
* The pending filter push-down PR: uses a value holder with a (type, value)
pair.
* The Impala solution: has nodes that represent literals, with subclasses
for various kinds of literal: `IntLiteral`, `StringLiteral`, etc.
* The JDBC approach: a separate schema that tells us that when `foo`
appears, it is an `int`, so we should use `getInt(colIndex)`.
* The `ColumnMetadata` (and HOCON config) approach; store values as strings,
parse to the desired type on demand.
Perhaps one of these (or, more likely, some combination) might help us here.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> Short-term fixes for metadata API parameterized type issues
> -----------------------------------------------------------
>
> Key: DRILL-7479
> URL: https://issues.apache.org/jira/browse/DRILL-7479
> Project: Apache Drill
> Issue Type: Task
> Affects Versions: 1.17.0
> Reporter: Paul Rogers
> Assignee: Paul Rogers
> Priority: Blocker
> Labels: ready-to-commit
> Fix For: 1.17.0
>
>
> See DRILL-7480 for a discussion of the issues with how we currently use
> parameterized types in the metadata API.
> This ticket is for short-term fixes that convert unsafe generic types of the
> form {{StatisticsHolder}} to the form {{StatisticsHolder<?>}} so that the
> compiler does not complain with many warnings (and a few Eclipse-only errors.)
> The topic should be revisited later in the context of DRILL-7480.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
