markap14 commented on pull request #4280: URL: https://github.com/apache/nifi/pull/4280#issuecomment-630338743
Hey @pcgrenier thanks for putting this PR up. I do think that it addresses the case when all of the values coming in have the same type. But if your schema says that field 'num' can be either an int or a float, this solutions forces the user to cast all values to either int or float. It stands to reason that with such a schema, you could have a mix of both ints and floats. And depending on the query, we may want to keep these values as such. I also would like to avoid adding our own custom "cast" functions when cast functions already exist in SQL. I definitely feel like that's a red flag that we're not doing something quite right. So I have a proposal that I think addresses this well but does so very differently. In the `FlowFileTable` class, we define the data types that Calcite should use internally for each of the types. For the CHOICE data type, we just blindly return `typeFactory.createJavaType(Object.class)` and that's why it fails - you can't cast an Object to a float, double, int, etc. So I think the better solution is to refine what we return for CHOICE types. Specifically, if we have a choice between two types of numbers where one is wider than the other, we should return the wider type (e.g., for a double/float we should return double). For two numbers where one is not wider than the other (e.g., double/int) we should return a String, as String is considered wider than both of these. For other cases, (e.g., double/Record) we should return Object as we do now. ---------------------------------------------------------------- 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]
