[jira] [Created] (HIVE-2939) LazyArray.getList changes array it previously returned
LazyArray.getList changes array it previously returned --- Key: HIVE-2939 URL: https://issues.apache.org/jira/browse/HIVE-2939 Project: Hive Issue Type: Bug Components: UDF Affects Versions: 0.8.1 Reporter: Igor Kabiljo Simple query like: SELECT a, e FROM ikabiljo_test_string_array LATERAL VIEW EXPLODE(a) x1 AS e (table contains one column - ARRAYSTRING - and has one row - [b,c,a] ) fails with ConcurrentModificationException, since LazyArray.getList changes the cached array it returns. LazyArray.getList can easily: - return cached array if present, without clearing and refiling. Hive is already not going to work properly if you change input parameters in an UDF. If that doesn't sound good - it can return Collections.unmodifiableList - or just not cache anything Same is true for LazyMap.getMap -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HIVE-2608) Do not require AS a,b,c part in LATERAL VIEW
Do not require AS a,b,c part in LATERAL VIEW Key: HIVE-2608 URL: https://issues.apache.org/jira/browse/HIVE-2608 Project: Hive Issue Type: Improvement Components: Query Processor, UDF Reporter: Igor Kabiljo Priority: Minor Currently, it is required to state column names when LATERAL VIEW is used. That shouldn't be necessary, since UDTF returns struct which contains column names - and they should be used by default. For example, it would be great if this was possible: SELECT t.*, t.key1 + t.key4 FROM some_table LATERAL VIEW JSON_TUPLE(json, 'key1', 'key2', 'key3', 'key3') t; -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HIVE-2541) Improve UDAF support for constant OI and better initialization
Improve UDAF support for constant OI and better initialization -- Key: HIVE-2541 URL: https://issues.apache.org/jira/browse/HIVE-2541 Project: Hive Issue Type: Improvement Components: UDF Reporter: Igor Kabiljo Currently, GenericUDAFs have only basic support for constant OIs - you can have constant OI as input, and check it in getEvaluator and in init() for mode where input is not partial, and that is all. For it to be fully useful, it would be great to have (not sure if this is best as 3 separate tickets, or one): - if output of terminate and terminatePartial is constantOI (or partially constant OI, ie struct with some constant and some non-constant fields), input of merge and next function should receive it as constant OI. - add initUDAFArguments(GenericUDAFParameterInfo info) to GenericUDAFEvaluator, that will be always called before init(Mode m, ObjectInspector[] argOIs). That would allow you to access constant OI information in all modes (currently in PARTIAL2 and FINAL modes it is not possible). GenericUDAFEvaluator should have default empty implementation, so that only classes that need that info can access it. - currently, when GenericUDAFEvaluator is returned by getEvaluator, all initialization done there (in constructor or elsewhere), is removed by serializing/deserializing it. (ie new instance of evaluator created by calling no args constructor is used). It would be great if fields would not be lost. This can be either achieved by fixing serialization/deserialization to save all fields as well (if that is possible by XMLEncoder), or by serializing/deserializing AbstractGenericUDAFResolver instead of Evaluator, and then calling getEvaluator whenever Evaluator is needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira