[jira] [Resolved] (TRAFODION-2003) Some classes named with the prefix HP instead of Traf
[ https://issues.apache.org/jira/browse/TRAFODION-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jian Jin resolved TRAFODION-2003. - Resolution: Fixed Fix Version/s: (was: 2.1-incubating) 2.0-incubating > Some classes named with the prefix HP instead of Traf > - > > Key: TRAFODION-2003 > URL: https://issues.apache.org/jira/browse/TRAFODION-2003 > Project: Apache Trafodion > Issue Type: Bug > Components: client-jdbc-t4 >Reporter: Kevin Xu >Assignee: Kevin Xu > Fix For: 2.0-incubating > > > Some classes named with the prefix HP instead of Traf. It's not consistent > while the others start Traf. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TRAFODION-2132) sqstop should check active connections up front
Gunnar Tapper created TRAFODION-2132: Summary: sqstop should check active connections up front Key: TRAFODION-2132 URL: https://issues.apache.org/jira/browse/TRAFODION-2132 Project: Apache Trafodion Issue Type: Bug Components: foundation Reporter: Gunnar Tapper Shutdown isn't clean when active connection exists. Often, the timeout mechanism kicks in but not always. In either case, you have to go find active connections and kill them. Or, use ckillall, which is a sledgehammer approach. It'd be preferable if sqstop started with checking active connections with DCS and sqlci, listed them, and then asked whether to terminate the connections or abort the stop action. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRAFODION-2076) [3rd party tool-Squirrel] call spj will return error though the procedure is actually executed successfully
[ https://issues.apache.org/jira/browse/TRAFODION-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jian Jin updated TRAFODION-2076: Assignee: mashengchen (was: Kevin Xu) > [3rd party tool-Squirrel] call spj will return error though the procedure is > actually executed successfully > > > Key: TRAFODION-2076 > URL: https://issues.apache.org/jira/browse/TRAFODION-2076 > Project: Apache Trafodion > Issue Type: Bug > Components: client-jdbc-t4 >Affects Versions: 2.1-incubating > Environment: Squirrel 3.7 > server info -- esgynDBadv R2.1, centos6.7, hbase1.0, cdh5.4.8 >Reporter: Gao, Rui-Xian >Assignee: mashengchen >Priority: Minor > > create library qa_dfr file '/home/trafodion/QALibs/SPJ/dfr.jar' > Create procedure createTable() > external name 'TestDDL.createTable' > LIBRARY qa_dfr > language java >NO TRANSACTION REQUIRED > parameter style java; > call createTable(); > Following error will be returned -- > java.lang.ClassCastException: org.trafodion.jdbc.t4.TrafT4Statement cannot be > cast to org.trafodion.jdbc.t4.TrafT4CallableStatement > But actually the table is created successfully. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRAFODION-2075) [3rd party tool] Squirrel doesn't support prepare/explain/excute, will return syntax error
[ https://issues.apache.org/jira/browse/TRAFODION-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jian Jin updated TRAFODION-2075: Assignee: mashengchen (was: Kevin Xu) > [3rd party tool] Squirrel doesn't support prepare/explain/excute, will return > syntax error > -- > > Key: TRAFODION-2075 > URL: https://issues.apache.org/jira/browse/TRAFODION-2075 > Project: Apache Trafodion > Issue Type: Bug > Components: client-jdbc-t4 >Affects Versions: 2.1-incubating > Environment: squirrel 3.7 > server with esgynDBadv R2.1, centos 6.7, hbase1.0 cdh 5.4.8 >Reporter: Gao, Rui-Xian >Assignee: mashengchen > > Prepare/explain/execute statement is not supported -- > prepare xx from select * from btsel02; > Error: *** ERROR[15001] A syntax error occurred at or before: > prepare xx from select * from btsel02; > ^ (22 characters from start of SQL statement) > [2016-06-20 17:07:00] > SQLState: 42000 > ErrorCode: -15001 > Error: *** ERROR[8822] The statement was not prepared. [2016-06-20 17:07:00] > SQLState: X08MU > ErrorCode: -8822 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRAFODION-2071) [3rd party tool] Squirrel return wrong value for interval data
[ https://issues.apache.org/jira/browse/TRAFODION-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jian Jin updated TRAFODION-2071: Assignee: mashengchen (was: Kevin Xu) > [3rd party tool] Squirrel return wrong value for interval data > -- > > Key: TRAFODION-2071 > URL: https://issues.apache.org/jira/browse/TRAFODION-2071 > Project: Apache Trafodion > Issue Type: Bug > Components: client-jdbc-t4 >Affects Versions: any > Environment: Centos6.7 hbase1.0 CDH5.4.8 >Reporter: Gao, Rui-Xian >Assignee: mashengchen > > create table ht(h10s4 interval hour(10) to second(4)) no partition; > insert into ht values(-interval '11:12:00.1234'hour(10) to second(4)); > From trafci -- > >>select * from ht; > H10S4 > -- > -11:12:00.1234 > --- 1 row(s) selected. > From Squirrel -- > select will return > checking with content button, it shows -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRAFODION-2077) [3rd party tool Squirrel] parameter is not support
[ https://issues.apache.org/jira/browse/TRAFODION-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jian Jin updated TRAFODION-2077: Assignee: mashengchen (was: Kevin Xu) > [3rd party tool Squirrel] parameter is not support > --- > > Key: TRAFODION-2077 > URL: https://issues.apache.org/jira/browse/TRAFODION-2077 > Project: Apache Trafodion > Issue Type: Bug > Components: client-jdbc-t4 >Affects Versions: 2.1-incubating > Environment: Squirrel 3.7 > server info -- esgynDBadv R2.1, centos 6.7, hbase 1.0, cdh5.4.8 >Reporter: Gao, Rui-Xian >Assignee: mashengchen > > set parameter will get syntax error with Squirrel -- > set param ?p1 B; > Error: *** ERROR[15001] A syntax error occurred at or before: > set param ?p1 B; > ^ (9 characters from start of SQL statement) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRAFODION-2078) [3rd party tool-Squirrel] query cancel is not supported
[ https://issues.apache.org/jira/browse/TRAFODION-2078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jian Jin updated TRAFODION-2078: Assignee: mashengchen (was: Kevin Xu) > [3rd party tool-Squirrel] query cancel is not supported > --- > > Key: TRAFODION-2078 > URL: https://issues.apache.org/jira/browse/TRAFODION-2078 > Project: Apache Trafodion > Issue Type: Bug > Components: client-jdbc-t4 >Affects Versions: 2.1-incubating > Environment: Squirrel 3.7 > server info -- esgynDBadv R2.1, centos6.7, hbase1.0, cdh5.4.8 >Reporter: Gao, Rui-Xian >Assignee: mashengchen > > can't cancel query from squirrel, syntax error returned -- > control query cancel qid > 'MXID11073282123331732153682000206U300_483_XX'; > Error: *** ERROR[15001] A syntax error occurred at or before: > control query cancel qid > 'MXID11073282123331732153682000206U300 > _483_XX'; >^ (87 characters from start of SQL statement) [2016-06-20 17:21:38] > SQLState: 42000 > ErrorCode: -15001 > Error: *** ERROR[8822] The statement was not prepared. [2016-06-20 17:21:38] > SQLState: X08MU > ErrorCode: -8822 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TRAFODION-2121) add support of HIVE data type of DECIMAL
[ https://issues.apache.org/jira/browse/TRAFODION-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] liu ming resolved TRAFODION-2121. - Resolution: Fixed Fix Version/s: 2.1-incubating > add support of HIVE data type of DECIMAL > > > Key: TRAFODION-2121 > URL: https://issues.apache.org/jira/browse/TRAFODION-2121 > Project: Apache Trafodion > Issue Type: Sub-task > Components: sql-cmp >Reporter: liu ming >Assignee: liu ming > Fix For: 2.1-incubating > > > support hive datatype DECIMAL and DECIMAL(p,s) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (TRAFODION-2131) UPDATE STATS cores, buffer overrun, on TINYINT and small INTERVAL cols
[ https://issues.apache.org/jira/browse/TRAFODION-2131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15396662#comment-15396662 ] David Wayne Birdsall edited comment on TRAFODION-2131 at 7/27/16 11:37 PM: --- Further debugging and testing revealed that in the first case UPDATE STATS was using a SELECT and casting the interval column to a TINYINT. In both cases, UPDATE STATS was using a rowset to retrieve the data values. It assumed the values would be 1 byte each. However, the compiler casts a TINYINT output to a 2-byte integer. The row set fetches would write two bytes per value to the rowset buffer. The high byte of one value would be overwritten by the low byte of the next (since this is was on a little-endian machine), and so the values would be correctly written to the rowset buffer until the last value. The last value would result in the high order byte being written past the end of the buffer. Sometimes this proved innocuous (the high order byte was often zero, for example, and the byte it was overwriting happened to be zero much of the time). However, with row counts of a multiple of 8, the overrun would typically clobber a memory pointer leading to a core. The fix is to change UPDATE STATS to use SMALLINT outputs for these data types instead. Another issue encountered while debugging this code on a later version of Trafodion was that when casting an INTERVAL YEAR(1) TO MONTH value down to a TINYINT, we would core in the compiler, in Cast::synthesizeType. The problem here was that a new routine, ExpGenerator::handleUnsupportedCast (generator/GenExpGenerator.cpp), was assuming that unsupported casts for code generation involving 8-byte integers always involved another numeric type. The fix is to take care of the case of interval types as well. Thanks to Anoop Sharma for diagnosing and providing the fix to this latter problem. was (Author: davebirdsall): Further debugging and testing revealed that in the first case UPDATE STATS was using a SELECT and casting the interval column to a TINYINT. In both cases, UPDATE STATS was using a rowset to retrieve the data values. It assumed the values would be 1 byte each. However, the compiler casts a TINYINT output to a 2-byte integer. The row set fetches would write two bytes per value to the rowset buffer. The high byte of one value would be overwritten by the low byte of the next (since this is was on a little-endian machine), and so the values would be correctly written to the rowset buffer until the last value. The last value would result in the high order byte being written past the end of the buffer. Sometimes this proved innocuous (the high order byte was often zero, for example, and the byte it was overwriting happened to be zero much of the time). However, with row counts of a multiple of 8, the overrun would typically clobber a memory pointer leading to a core. The fix is to change UPDATE STATS to use SMALLINT outputs for these data types instead. Another issue encountered while debugging this code on a later version of Trafodion was that when casting an INTERVAL YEAR(1) TO MONTH value down to a TINYINT, we would core in the compiler, in Cast::synthesizeType. The problem here was that a new routine, ExpGenerator::handleUnsupportedCast (generator/GenExpGenerator.cpp), was assuming that unsupported casts for code generation involving 8-byte integers always involved another numeric type. The fix is to take care of the case of interval types as well. > UPDATE STATS cores, buffer overrun, on TINYINT and small INTERVAL cols > -- > > Key: TRAFODION-2131 > URL: https://issues.apache.org/jira/browse/TRAFODION-2131 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-cmp >Affects Versions: 2.1-incubating > Environment: All >Reporter: David Wayne Birdsall >Assignee: David Wayne Birdsall > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-2131) UPDATE STATS cores, buffer overrun, on TINYINT and small INTERVAL cols
[ https://issues.apache.org/jira/browse/TRAFODION-2131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15396662#comment-15396662 ] David Wayne Birdsall commented on TRAFODION-2131: - Further debugging and testing revealed that in the first case UPDATE STATS was using a SELECT and casting the interval column to a TINYINT. In both cases, UPDATE STATS was using a rowset to retrieve the data values. It assumed the values would be 1 byte each. However, the compiler casts a TINYINT output to a 2-byte integer. The row set fetches would write two bytes per value to the rowset buffer. The high byte of one value would be overwritten by the low byte of the next (since this is was on a little-endian machine), and so the values would be correctly written to the rowset buffer until the last value. The last value would result in the high order byte being written past the end of the buffer. Sometimes this proved innocuous (the high order byte was often zero, for example, and the byte it was overwriting happened to be zero much of the time). However, with row counts of a multiple of 8, the overrun would typically clobber a memory pointer leading to a core. The fix is to change UPDATE STATS to use SMALLINT outputs for these data types instead. Another issue encountered while debugging this code on a later version of Trafodion was that when casting an INTERVAL YEAR(1) TO MONTH value down to a TINYINT, we would core in the compiler, in Cast::synthesizeType. The problem here was that a new routine, ExpGenerator::handleUnsupportedCast (generator/GenExpGenerator.cpp), was assuming that unsupported casts for code generation involving 8-byte integers always involved another numeric type. The fix is to take care of the case of interval types as well. > UPDATE STATS cores, buffer overrun, on TINYINT and small INTERVAL cols > -- > > Key: TRAFODION-2131 > URL: https://issues.apache.org/jira/browse/TRAFODION-2131 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-cmp >Affects Versions: 2.1-incubating > Environment: All >Reporter: David Wayne Birdsall >Assignee: David Wayne Birdsall > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-2131) UPDATE STATS cores, buffer overrun, on TINYINT and small INTERVAL cols
[ https://issues.apache.org/jira/browse/TRAFODION-2131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15396648#comment-15396648 ] David Wayne Birdsall commented on TRAFODION-2131: - The problem was first noticed on a test table involving an INTERVAL YEAR(1) TO MONTH column. When UPDATE STATISTICS was done on such a table (and there was data in it), we would get a core like the following: (gdb) bt #0 0x7f7167583625 in raise () from /lib64/libc.so.6 #1 0x7f7167584e05 in abort () from /lib64/libc.so.6 #2 0x7f716757c74e in __assert_fail_base () from /lib64/libc.so.6 #3 0x7f716757c810 in __assert_fail () from /lib64/libc.so.6 #4 0x7f7170fedacd in NAHeap::doCheckInuseFragment (this=0x7f7150b34958, p=0x7f714fedc0f0) at ../common/NAMemory.cpp:3960 #5 0x7f7170fec026 in NAHeap::deallocateHeapMemory (this=0x7f7150b34958, addr=0x7f714fedc100) at ../common/NAMemory.cpp:3508 #6 0x7f7170fe792b in NAMemory::deallocateMemory (this=0x7f7150b34958, addr=0x7f714fedc100) at ../common/NAMemory.cpp:1399 #7 0x7f716fcebafe in HSColGroupStruct::freeISMemory (this=0x7f7150b38258, freeStrData=1, freeMCData=1) at ../ustat/hs_globals.cpp:1615 #8 0x7f716fd0d9b6 in HSGlobalsClass::createStatsForColumn ( this=0x7ffc35255b60, group=0x7f7150b38258, rowsAllocated=2144) at ../ustat/hs_globals.cpp:11546 #9 0x7f716fd0d06a in HSGlobalsClass::createStats (this=0x7ffc35255b60, rowsAllocated=2144) at ../ustat/hs_globals.cpp:11409 #10 0x7f716fcf95ce in HSGlobalsClass::CollectStatistics ( this=0x7ffc35255b60) at ../ustat/hs_globals.cpp:5570 #11 0x7f716fd7ddd1 in UpdateStats ( input=0x7f7150b825d8 "update statistics for table b2uwl02g on int3_ytom_4;", requestedByCompiler=0) at ../ustat/hs_update.cpp:432 Later, it was noticed that similar cores occur on TINYINT columns as well. > UPDATE STATS cores, buffer overrun, on TINYINT and small INTERVAL cols > -- > > Key: TRAFODION-2131 > URL: https://issues.apache.org/jira/browse/TRAFODION-2131 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-cmp >Affects Versions: 2.1-incubating > Environment: All >Reporter: David Wayne Birdsall >Assignee: David Wayne Birdsall > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TRAFODION-2131) UPDATE STATS cores, buffer overrun, on TINYINT and small INTERVAL cols
David Wayne Birdsall created TRAFODION-2131: --- Summary: UPDATE STATS cores, buffer overrun, on TINYINT and small INTERVAL cols Key: TRAFODION-2131 URL: https://issues.apache.org/jira/browse/TRAFODION-2131 Project: Apache Trafodion Issue Type: Bug Components: sql-cmp Affects Versions: 2.1-incubating Environment: All Reporter: David Wayne Birdsall Assignee: David Wayne Birdsall -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-2121) add support of HIVE data type of DECIMAL
[ https://issues.apache.org/jira/browse/TRAFODION-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15396298#comment-15396298 ] ASF GitHub Bot commented on TRAFODION-2121: --- Github user asfgit closed the pull request at: https://github.com/apache/incubator-trafodion/pull/618 > add support of HIVE data type of DECIMAL > > > Key: TRAFODION-2121 > URL: https://issues.apache.org/jira/browse/TRAFODION-2121 > Project: Apache Trafodion > Issue Type: Sub-task > Components: sql-cmp >Reporter: liu ming >Assignee: liu ming > > support hive datatype DECIMAL and DECIMAL(p,s) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (TRAFODION-2130) Incorrect subquery transformation for tables w/o key
[ https://issues.apache.org/jira/browse/TRAFODION-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TRAFODION-2130 started by Hans Zeller. -- > Incorrect subquery transformation for tables w/o key > > > Key: TRAFODION-2130 > URL: https://issues.apache.org/jira/browse/TRAFODION-2130 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-cmp >Affects Versions: 1.2-incubating >Reporter: Hans Zeller >Assignee: Hans Zeller > > Some of the subquery unnesting transformations rely on a unique key on the > result of the main query. It turns out, however, that the transformation > happens even if there is no unique key. Example: > select * > from (values (1,1), (1,1), (2,2)) T(a,b) > where t.a in (select max(a) > from (values (1,1), (1,1), (3,3)) S(a,b) > where S.b = T.b); > This should return two rows, but it actually just returns one, because it > does not include a unique key for the main query, T. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRAFODION-2130) Incorrect subquery transformation for tables w/o key
[ https://issues.apache.org/jira/browse/TRAFODION-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hans Zeller updated TRAFODION-2130: --- Description: Some of the subquery unnesting transformations rely on a unique key on the result of the main query. It turns out, however, that the transformation happens even if there is no unique key. Example: select * from (values (1,1), (1,1), (2,2)) T(a,b) where t.a in (select max(a) from (values (1,1), (1,1), (3,3)) S(a,b) where S.b = T.b); This should return two rows, but it actually just returns one, because it does not include a unique key for the main query, T. was:Some of the subquery unnesting transformations rely on a unique key on the result of the main query. > Incorrect subquery transformation for tables w/o key > > > Key: TRAFODION-2130 > URL: https://issues.apache.org/jira/browse/TRAFODION-2130 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-cmp >Affects Versions: 1.2-incubating >Reporter: Hans Zeller > > Some of the subquery unnesting transformations rely on a unique key on the > result of the main query. It turns out, however, that the transformation > happens even if there is no unique key. Example: > select * > from (values (1,1), (1,1), (2,2)) T(a,b) > where t.a in (select max(a) > from (values (1,1), (1,1), (3,3)) S(a,b) > where S.b = T.b); > This should return two rows, but it actually just returns one, because it > does not include a unique key for the main query, T. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRAFODION-2130) Incorrect subquery transformation for tables w/o key
[ https://issues.apache.org/jira/browse/TRAFODION-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hans Zeller updated TRAFODION-2130: --- Component/s: sql-cmp > Incorrect subquery transformation for tables w/o key > > > Key: TRAFODION-2130 > URL: https://issues.apache.org/jira/browse/TRAFODION-2130 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-cmp >Affects Versions: 1.2-incubating >Reporter: Hans Zeller > > Some of the subquery unnesting transformations rely on a unique key on the > result of the main query. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRAFODION-2130) Incorrect subquery transformation for tables w/o key
[ https://issues.apache.org/jira/browse/TRAFODION-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hans Zeller updated TRAFODION-2130: --- Description: Some of the subquery unnesting transformations rely on a unique key on the result of the main query. > Incorrect subquery transformation for tables w/o key > > > Key: TRAFODION-2130 > URL: https://issues.apache.org/jira/browse/TRAFODION-2130 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-cmp >Affects Versions: 1.2-incubating >Reporter: Hans Zeller > > Some of the subquery unnesting transformations rely on a unique key on the > result of the main query. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRAFODION-2130) Incorrect subquery transformation for tables w/o key
[ https://issues.apache.org/jira/browse/TRAFODION-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hans Zeller updated TRAFODION-2130: --- Affects Version/s: 1.2-incubating > Incorrect subquery transformation for tables w/o key > > > Key: TRAFODION-2130 > URL: https://issues.apache.org/jira/browse/TRAFODION-2130 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-cmp >Affects Versions: 1.2-incubating >Reporter: Hans Zeller > > Some of the subquery unnesting transformations rely on a unique key on the > result of the main query. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRAFODION-2130) Incorrect subquery transformation for tables w/o key
[ https://issues.apache.org/jira/browse/TRAFODION-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hans Zeller updated TRAFODION-2130: --- Summary: Incorrect subquery transformation for tables w/o key (was: Incorrect subquery tran) > Incorrect subquery transformation for tables w/o key > > > Key: TRAFODION-2130 > URL: https://issues.apache.org/jira/browse/TRAFODION-2130 > Project: Apache Trafodion > Issue Type: Bug >Reporter: Hans Zeller > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TRAFODION-2130) Incorrect subquery tran
Hans Zeller created TRAFODION-2130: -- Summary: Incorrect subquery tran Key: TRAFODION-2130 URL: https://issues.apache.org/jira/browse/TRAFODION-2130 Project: Apache Trafodion Issue Type: Bug Reporter: Hans Zeller -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TRAFODION-2129) Trafodion to avoid use of deprecated HBase APIs/Classes
Selvaganesan Govindarajan created TRAFODION-2129: Summary: Trafodion to avoid use of deprecated HBase APIs/Classes Key: TRAFODION-2129 URL: https://issues.apache.org/jira/browse/TRAFODION-2129 Project: Apache Trafodion Issue Type: Improvement Components: dtm, sql-exe Affects Versions: 2.0-incubating Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan Avoid the use of HConnection, HConnectionManager and, HBaseAdmin in Trafodion and use Connection, ConnectionFactory and Admin respectively. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-2121) add support of HIVE data type of DECIMAL
[
https://issues.apache.org/jira/browse/TRAFODION-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15395291#comment-15395291
]
ASF GitHub Bot commented on TRAFODION-2121:
---
Github user traflm commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/618#discussion_r72406115
--- Diff: core/sql/optimizer/NATable.cpp ---
@@ -3676,6 +3680,76 @@ NAType* getSQColTypeForHive(const char* hiveType,
NAMemory* heap)
CharInfo::IMPLICIT);
}
+ if ( !strncmp(hiveType, "decimal", 7) )
+ {
+Lng32 i=0, pstart=0, pend=0, sstart=0, send=0, p=-1, s = -1;
+Lng32 hiveTypeLen = strlen(hiveType);
+char pstr[MAX_NUM_LEN], sstr[MAX_NUM_LEN];
+memset(pstr,0,sizeof(pstr));
+memset(sstr,0,sizeof(sstr));
+
+for( i = 0; i < hiveTypeLen; i++ )
+{
+ if(hiveType[i] == '(' )
+ {
+pstart = i+1;
+ }
+ else if(hiveType[i] == ',')
+ {
+pend = i;
+sstart = i+1;
+ }
+ else if(hiveType[i] == ')')
+ {
+send = i;
+ }
+ else
+ continue;
+}
+
+if(pend - pstart > 0)
--- End diff --
@zellerh , I found Hive will do a kind of normalization here. If we use
DECIMAL(4) in DDL, hive will transform it into decimal(4,0) and that is what
Trafodion will get and parse it.
So all the checkings here are not necessary, but I still want to leave it
since it doesn't harm and not impact performance too much, this is not hot
path.
> add support of HIVE data type of DECIMAL
>
>
> Key: TRAFODION-2121
> URL: https://issues.apache.org/jira/browse/TRAFODION-2121
> Project: Apache Trafodion
> Issue Type: Sub-task
> Components: sql-cmp
>Reporter: liu ming
>Assignee: liu ming
>
> support hive datatype DECIMAL and DECIMAL(p,s)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
