[jira] [Commented] (TRAFODION-2091) hdfsFS filesystem usage causies abnormal behavior in Trafodion

2016-07-05 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TRAFODION-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15363504#comment-15363504
 ] 

ASF GitHub Bot commented on TRAFODION-2091:
---

Github user sandhyasun commented on a diff in the pull request:

https://github.com/apache/incubator-trafodion/pull/574#discussion_r69658107
  
--- Diff: core/sql/src/main/java/org/trafodion/sql/HBulkLoadClient.java ---
@@ -475,10 +475,12 @@ public boolean release( ) throws IOException {
writer.close();
writer = null;
 }
-if (fileSys !=null)
+// sss This is one place that is unconditionally closing the 
--- End diff --

WIll change this.


> hdfsFS filesystem usage causies abnormal  behavior in Trafodion
> ---
>
> Key: TRAFODION-2091
> URL: https://issues.apache.org/jira/browse/TRAFODION-2091
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-general
>Affects Versions: 2.1-incubating
>Reporter: Sandhya Sundaresan
>Assignee: Sandhya Sundaresan
>
> Several components use the libhdfs API to perform operations on hdfs files in 
> Trafodion. Some places use the JNI API as well to access hdfs. 
> The inconsistency observed was ehen one component cached and kept the hdfsFS 
> hande for it's use another part of the code would perform a "close" or a 
> dsconnect and prematurely close the hdfsFS handle which is currently being 
> used. The reason is that the hdfs layer seems to cache the hdfsFS handle 
> underneathThe solution now is to keep a list of hdfsFS handles at the global 
> context level. All disconnect calls and JNI close calls are remmoved. The 
> hdfHS handles will get cleaned up either at context destructor time or at 
> endSession time. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (TRAFODION-2094) ODB TRUNCATE option takes a long time

2016-07-05 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TRAFODION-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15363316#comment-15363316
 ] 

ASF GitHub Bot commented on TRAFODION-2094:
---

GitHub user sureshsubbiah opened a pull request:

https://github.com/apache/incubator-trafodion/pull/576

[TRAFODION-2094] Truncate option slow in ODB

Mispaced paranthesis causes us to take the generic database codepath,
with dbt = 0, instead of dbt = 8 for Trafodion.
All compiler warnings for ODB are now fixed or suppressed.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sureshsubbiah/incubator-trafodion traf-2094

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-trafodion/pull/576.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #576


commit 7166c64db17e3b5f457b55dc1c491a01b070dcbc
Author: Suresh Subbiah 
Date:   2016-07-05T21:42:26Z

[TRAFODION-2094] Truncate option slow in ODB

Misplaced paranthesis caused ODB to not recognize Trafodion database.
We were going through the generic codepath.
Also made some changes to remove/suppress compiler warnings.




> ODB TRUNCATE option takes a long time
> -
>
> Key: TRAFODION-2094
> URL: https://issues.apache.org/jira/browse/TRAFODION-2094
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: db-utility-odb
>Reporter: Suresh Subbiah
>Assignee: Suresh Subbiah
>
> Truncate option of ODB uses DELETE command. This works too slowly for large 
> tables and may run into transaction issues.
> Will be changed to use PURGEDATA instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (TRAFODION-1239) LP Bug: 1455670 - insert using params to varchar column of > 32k colsize fails

2016-07-05 Thread Sandhya Sundaresan (JIRA)

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

Sandhya Sundaresan resolved TRAFODION-1239.
---
Resolution: Fixed

> LP Bug: 1455670 - insert using params to varchar column of > 32k colsize fails
> --
>
> Key: TRAFODION-1239
> URL: https://issues.apache.org/jira/browse/TRAFODION-1239
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: client-jdbc-t4
>Reporter: Aruna Sadashiva
>Assignee: Arvind Narain
>Priority: Blocker
> Fix For: 2.1-incubating
>
>
> Using bound params, insert into varchar column of colsize >32k fails with 
> string overflow error.
> To reproduce using Trafci :
> SQL>CREATE TABLE TAB3  ( A INT, B VARCHAR(4));
> --- SQL operation complete.
> SQL>prepare s from insert into tab3 values(?a, ?b);
> --- SQL command prepared.
> SQL>set param ?a 100;
> SQL>set param ?b 'aaaZZ';
> SQL>execute s;
> *** ERROR[8402] A string overflow occurred during the evaluation of a 
> character expression. [2015-05-15 21:27:01]
> Steps from sqlci:
> >>create table a3(a int, b varchar(32000));
> --- SQL operation complete.
> >>prepare s1 from insert into a3 values(?a,?b);
> --- SQL command prepared.
> >>set param ?a 1;
> >>set param ?b 'aaaZZ';
> >>execute s1;
> --- 1 row(s) inserted.
> >>create table a4(a int, b varchar(4));
> --- SQL operation complete.
> >>prepare s2 from insert into a4 values(?a,?b);
> --- SQL command prepared.
> >>set param ?a 1;
> >>set param ?b 'bbbZZ';
> >>execute s2;
> *** ERROR[8402] A string overflow occurred during the evaluation of a 
> character expression.
> --- 0 row(s) inserted.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (TRAFODION-2069) 'sqcheck' script should not report on hosts in TRAF_EXCLUDE_LIST

2016-07-05 Thread Gonzalo E Correa (JIRA)

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

Gonzalo E Correa resolved TRAFODION-2069.
-
Resolution: Fixed

> 'sqcheck' script should not report on hosts in TRAF_EXCLUDE_LIST
> 
>
> Key: TRAFODION-2069
> URL: https://issues.apache.org/jira/browse/TRAFODION-2069
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: foundation
>Affects Versions: 2.1-incubating
>Reporter: Gonzalo E Correa
>Assignee: Gonzalo E Correa
> Fix For: 2.1-incubating
>
>
> The 'sqcheck' script does not evaluate the contents of the TRAF_EXCLUDE_LIST 
> environment variable when the elasticity feature is used. Script logic 
> calculating configured process type counts needs to account for non-existent 
> nodes to calculate number of configured processes accurately.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (TRAFODION-2008) Support for external file LOBs in Trafodion

2016-07-05 Thread Sandhya Sundaresan (JIRA)

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

Sandhya Sundaresan resolved TRAFODION-2008.
---
Resolution: Fixed

> Support for external file LOBs in Trafodion
> ---
>
> Key: TRAFODION-2008
> URL: https://issues.apache.org/jira/browse/TRAFODION-2008
> Project: Apache Trafodion
>  Issue Type: New Feature
>  Components: sql-exe
>Reporter: Sandhya Sundaresan
>Assignee: Sandhya Sundaresan
> Fix For: 2.1-incubating
>
>
> Add support for  a new lobtype and lob function (externaltolob) that will 
> allow files to reside in HDFS outside o Trafodion. The file is not imported 
> nor part of Trafodion but the file lcoator will be a part of the Trafodion 
> column.
> Once a column is declared with the "external" attribute, it cannot contain an 
> internal LOB type . All data that's part of that column will have to reside 
> outside Trafodion. Similarly if a column is declared as a regular blob/clb, 
> then an external file cannot be linked to that column using the externaltolob 
> function.
> Also external file LOBs can be inserted or updated. They cannot be 
> "appended". So each  a particular LOB value in a column can be pointing to 
> just one external file . It cannot point ot multiple files so append is not 
> allowed. 
> If an external LOB is updated or modified by the user outside Trafodion,t he 
> user will need to do an "update" to update the information in the Trafodion 
> LOB column. If not, the information in the Trafodion table will be stale. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (TRAFODION-2094) ODB TRUNCATE option takes a long time

2016-07-05 Thread Suresh Subbiah (JIRA)
Suresh Subbiah created TRAFODION-2094:
-

 Summary: ODB TRUNCATE option takes a long time
 Key: TRAFODION-2094
 URL: https://issues.apache.org/jira/browse/TRAFODION-2094
 Project: Apache Trafodion
  Issue Type: Bug
  Components: db-utility-odb
Reporter: Suresh Subbiah
Assignee: Suresh Subbiah


Truncate option of ODB uses DELETE command. This works too slowly for large 
tables and may run into transaction issues.

Will be changed to use PURGEDATA instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (TRAFODION-1609) Change swstatus to give a simple "up" or "down" answer, instead of the current, confusing display

2016-07-05 Thread Jian Jin (JIRA)

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

Jian Jin resolved TRAFODION-1609.
-
   Resolution: Fixed
Fix Version/s: 2.1-incubating

> Change swstatus to give a simple "up" or "down" answer, instead of the 
> current, confusing display
> -
>
> Key: TRAFODION-1609
> URL: https://issues.apache.org/jira/browse/TRAFODION-1609
> Project: Apache Trafodion
>  Issue Type: Improvement
>  Components: sql-general
>Reporter: Hans Zeller
>Assignee: Eason Zhang
>Priority: Minor
> Fix For: 2.1-incubating
>
>
> The "swstatus" script used in cases where we did install_local_hadoop counts 
> the MySQL processes and then simply invokes jps.
> It would be better if the script would check specifically for HMaster, 
> NameNode, DataNode and maybe others, like NodeManager and ResourceManager. If 
> any are missing, it should print out which ones are missing, otherwise it 
> should just say something like "processes are up".
> It should also return an exit code of 0 if everything is up and 1 if some 
> processes are missing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (TRAFODION-1609) Change swstatus to give a simple "up" or "down" answer, instead of the current, confusing display

2016-07-05 Thread Jian Jin (JIRA)

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

Jian Jin updated TRAFODION-1609:

Assignee: Eason Zhang  (was: Jian Jin)

> Change swstatus to give a simple "up" or "down" answer, instead of the 
> current, confusing display
> -
>
> Key: TRAFODION-1609
> URL: https://issues.apache.org/jira/browse/TRAFODION-1609
> Project: Apache Trafodion
>  Issue Type: Improvement
>  Components: sql-general
>Reporter: Hans Zeller
>Assignee: Eason Zhang
>Priority: Minor
>
> The "swstatus" script used in cases where we did install_local_hadoop counts 
> the MySQL processes and then simply invokes jps.
> It would be better if the script would check specifically for HMaster, 
> NameNode, DataNode and maybe others, like NodeManager and ResourceManager. If 
> any are missing, it should print out which ones are missing, otherwise it 
> should just say something like "processes are up".
> It should also return an exit code of 0 if everything is up and 1 if some 
> processes are missing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (TRAFODION-1676) support better runtime error message when a SQL function meet fital error

2016-07-05 Thread liu ming (JIRA)

[ 
https://issues.apache.org/jira/browse/TRAFODION-1676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362591#comment-15362591
 ] 

liu ming commented on TRAFODION-1676:
-

This PR (564) enhance error messages for these SQL Errors:
EXE_CONVERTTIMESTAMP_ERROR = 8405,
EXE_JULIANTIMESTAMP_ERROR = 8407,
EXE_CONVERT_STRING_ERROR = 8413
EXE_CONVERT_DATETIME_ERROR = 8415,

By displaying the offending source data content, for CONVERT_STRING_ERROR, 
because it always contains multi-byte character, so display the data in HEX 
mode.

> support better runtime error message when a SQL function meet fital error
> -
>
> Key: TRAFODION-1676
> URL: https://issues.apache.org/jira/browse/TRAFODION-1676
> Project: Apache Trafodion
>  Issue Type: Improvement
>  Components: sql-exe
>Reporter: liu ming
>Assignee: liu ming
>Priority: Minor
>
> A sql contains some SQL function, for example UPPER(), when the input data of 
> UPPER() contains invalid data, UPPER() will fail. In this case, the whole 
> query abort, and the error message cannot tell which row has invalid data, so 
> it is very hard to fix the problem.
> It will be good to have row id or the real value of the error row in the 
> error message to help trouble shooting.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (TRAFODION-2034) Cannot output bad records in the loaded file even if specified file for storing bad records

2016-07-05 Thread Jian Jin (JIRA)

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

Jian Jin resolved TRAFODION-2034.
-
   Resolution: Fixed
Fix Version/s: 2.1-incubating

> Cannot output bad records in the loaded file even if specified file for 
> storing bad records
> ---
>
> Key: TRAFODION-2034
> URL: https://issues.apache.org/jira/browse/TRAFODION-2034
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: db-utility-odb
> Environment: centos6.7 HBase 1.0.0-cdh5.4.8
>Reporter: zhangliang
>Assignee: zhangliang
>Priority: Minor
> Fix For: 2.1-incubating
>
>
> This issue is from mantis 330.
> Load file where is bad record in it, with option bad=output_data/bad_records 
> to hold the bad records, but the result is the file output_data/bad_records 
> generated but it is empty lines.
> [root@suse-1 odb_test]# ./odb64luo -u trafodion -p traf123 -d traf -l 
> src=output_data/ext_person3.csv:pre=@scripts/ddl_person3.sql:tgt=trafodion.odb_test.person3:max=1000:rows=5000:parallel=5:loadcmd=UL:fs=\|:sq=\":bad=output_data/bad_records
> odb [2016-04-25 19:17:05]: starting ODBC connection(s)... 0 1 2 3 4 5
> [0.0.0]Executing: 'drop table TRAFODION.odb_test.person3;'
> [0.0.0]--- command executed in 7.279s (prep 0.001s, exec 7.278s, fetch 
> 0.000s/0.000s)
> [0.0.1]Executing: 'CREATE TABLE TRAFODION.odb_test."PERSON3" (
> PID BIGINT SIGNED NOT NULL
> ,FNAME CHAR(20) NOT NULL
> ,LNAME CHAR(20) NOT NULL
> ,COUNTRY VARCHAR(40) NOT NULL
> ,CITY VARCHAR(40) NOT NULL
> ,BDATE DATE NOT NULL
> ,SEX CHAR(1) NOT NULL
> ,EMAIL VARCHAR(40) NOT NULL
> ,SALARY NUMERIC(9,2) NOT NULL
> ,EMPL VARCHAR(40) NOT NULL
> ,NOTES VARCHAR(80)
> ,LOADTS TIMESTAMP(0)
> ,PRIMARY KEY (PID)
> );'
> [0.0.1]--- command executed in 1.388s (prep 0.002s, exec 1.386s, fetch 
> 0.000s/0.000s)
> Connected to Trafodion
> [1] odb [Oloadbuff(9438)] - Error loading row 5 (State: 23000, Native 0)
> [Trafodion ODBC Driver] GENERAL ERROR. Null Value in a non nullable column. 
> Row: 5 Column: 1
> [1] 999 records inserted [commit]
> [0] odb version 1.1.0 Load statistics:
> [0] Target table: TRAFODION.ODB_TEST.PERSON3
> [0] Source: output_data/ext_person3.csv
> [0] Pre-loading time: 10.920 s (00:00:10.920)
> [0] Loading time: 0.127 s(00:00:00.127)
> [0] Total records read: 1,000
> [0] Total records inserted: 999
> [0] Total number of columns: 12
> [0] Total bytes read: 180,517
> [0] Average input row size: 180.5 B
> [0] ODBC row size: 341 B (data) + 96 B (len ind)
> [0] Rowset size: 1,000
> [0] Rowset buffer size: 426.76 KiB
> [0] Load throughput (real data): 1,388.080 KiB/s
> [0] Load throughput (ODBC): 2,619.487 KiB/s
> [0] Reader Total/Wait Cycles: 1/0
> odb [2016-04-25 19:17:16]: exiting. Session Elapsed time 11.060 seconds 
> (00:00:11.060)
> SQL>showddl person3;
>  
> CREATE TABLE TRAFODION.ODB_TEST.PERSON3
>   (
> PID LARGEINT NO DEFAULT NOT NULL NOT DROPPABLE
>   SERIALIZED
>   , FNAME CHAR(20) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , LNAME CHAR(20) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , COUNTRY VARCHAR(40) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , CITY VARCHAR(40) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , BDATE DATE NO DEFAULT NOT NULL NOT DROPPABLE NOT
>   SERIALIZED
>   , SEX CHAR(1) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , EMAIL VARCHAR(40) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , SALARY NUMERIC(9, 2) NO DEFAULT NOT NULL NOT
>   DROPPABLE SERIALIZED
>   , EMPL VARCHAR(40) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , NOTES VARCHAR(80) CHARACTER SET ISO88591 COLLATE
>   DEFAULT DEFAULT NULL SERIALIZED
>   , LOADTS TIMESTAMP(0) DEFAULT NULL NOT SERIALIZED
>   , PRIMARY KEY (PID ASC)
>   )
> ;
> --- SQL operation complete.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Work started] (TRAFODION-1609) Change swstatus to give a simple "up" or "down" answer, instead of the current, confusing display

2016-07-05 Thread Jian Jin (JIRA)

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

Work on TRAFODION-1609 started by Jian Jin.
---
> Change swstatus to give a simple "up" or "down" answer, instead of the 
> current, confusing display
> -
>
> Key: TRAFODION-1609
> URL: https://issues.apache.org/jira/browse/TRAFODION-1609
> Project: Apache Trafodion
>  Issue Type: Improvement
>  Components: sql-general
>Reporter: Hans Zeller
>Assignee: Jian Jin
>Priority: Minor
>
> The "swstatus" script used in cases where we did install_local_hadoop counts 
> the MySQL processes and then simply invokes jps.
> It would be better if the script would check specifically for HMaster, 
> NameNode, DataNode and maybe others, like NodeManager and ResourceManager. If 
> any are missing, it should print out which ones are missing, otherwise it 
> should just say something like "processes are up".
> It should also return an exit code of 0 if everything is up and 1 if some 
> processes are missing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (TRAFODION-2093) Licensing issues found during review of release 2.0.1

2016-07-05 Thread Roberta Marton (JIRA)

[ 
https://issues.apache.org/jira/browse/TRAFODION-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362572#comment-15362572
 ] 

Roberta Marton commented on TRAFODION-2093:
---

Link to email: 

http://mail-archives.apache.org/mod_mbox/incubator-general/201607.mbox/ajax/%3C2CF860BA-8473-4F9F-A570-72931EE7FB0A%40classsoftware.com%3E


> Licensing issues found during review of release 2.0.1
> -
>
> Key: TRAFODION-2093
> URL: https://issues.apache.org/jira/browse/TRAFODION-2093
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: Build Infrastructure
>Reporter: Roberta Marton
>
> The following issues were reported during the review our our 2.0.1 release 
> package. They should be fixed for the next release:
> "I’m also a little confused by “trafodion_license” in the installer as it 
> states:
> “Project Trafodion includes third party copyrighted software components, 
> which may be licensed under third party and or open source license terms as 
> set forth in the LICENSE.TXT file accompanying the Project Trafodion 
> distribution or as indicated in the applicable source code file.”
> But LICENSE (not LICENSE.TXT) has no 3rd party software. Is the 
> trafodion_license file even needed?
> With the addition of the new 3 clause BSD licenses the number “2” is the 
> second license point has been dropped, you might want to fix that."



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (TRAFODION-2092) Names of installer tar file in release package incorrect

2016-07-05 Thread Roberta Marton (JIRA)

[ 
https://issues.apache.org/jira/browse/TRAFODION-2092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362571#comment-15362571
 ] 

Roberta Marton commented on TRAFODION-2092:
---

link to email: 
http://mail-archives.apache.org/mod_mbox/incubator-general/201607.mbox/ajax/%3C2CF860BA-8473-4F9F-A570-72931EE7FB0A%40classsoftware.com%3E


> Names of installer tar file in release package incorrect
> 
>
> Key: TRAFODION-2092
> URL: https://issues.apache.org/jira/browse/TRAFODION-2092
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: Build Infrastructure
>Reporter: Roberta Marton
>
> A comment received from the IPMC during our release process:
> Is there any reason for the installer to not include apache-trafodion and 
> incubating? Please fix for next release.
> In addition, we should make all the names for our released tar file follow 
> the same format.  There seems to be 3 different formats.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (TRAFODION-2092) Names of installer tar file in release package incorrect

2016-07-05 Thread Roberta Marton (JIRA)
Roberta Marton created TRAFODION-2092:
-

 Summary: Names of installer tar file in release package incorrect
 Key: TRAFODION-2092
 URL: https://issues.apache.org/jira/browse/TRAFODION-2092
 Project: Apache Trafodion
  Issue Type: Bug
  Components: Build Infrastructure
Reporter: Roberta Marton


A comment received from the IPMC during our release process:

Is there any reason for the installer to not include apache-trafodion and 
incubating? Please fix for next release.

In addition, we should make all the names for our released tar file follow the 
same format.  There seems to be 3 different formats.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (TRAFODION-2093) Licensing issues found during review of release 2.0.1

2016-07-05 Thread Roberta Marton (JIRA)
Roberta Marton created TRAFODION-2093:
-

 Summary: Licensing issues found during review of release 2.0.1
 Key: TRAFODION-2093
 URL: https://issues.apache.org/jira/browse/TRAFODION-2093
 Project: Apache Trafodion
  Issue Type: Bug
  Components: Build Infrastructure
Reporter: Roberta Marton


The following issues were reported during the review our our 2.0.1 release 
package. They should be fixed for the next release:

"I’m also a little confused by “trafodion_license” in the installer as it 
states:
“Project Trafodion includes third party copyrighted software components, which 
may be licensed under third party and or open source license terms as set forth 
in the LICENSE.TXT file accompanying the Project Trafodion distribution or as 
indicated in the applicable source code file.”

But LICENSE (not LICENSE.TXT) has no 3rd party software. Is the 
trafodion_license file even needed?

With the addition of the new 3 clause BSD licenses the number “2” is the second 
license point has been dropped, you might want to fix that."




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (TRAFODION-2091) hdfsFS filesystem usage causies abnormal behavior in Trafodion

2016-07-05 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TRAFODION-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362524#comment-15362524
 ] 

ASF GitHub Bot commented on TRAFODION-2091:
---

Github user sureshsubbiah commented on a diff in the pull request:

https://github.com/apache/incubator-trafodion/pull/574#discussion_r69567976
  
--- Diff: core/sql/cli/Context.cpp ---
@@ -298,6 +299,8 @@ ContextCli::ContextCli(CliGlobals *cliGlobals)
 
   seqGen_ = new(exCollHeap()) SequenceValueGenerator(exCollHeap());
 
+  hdfsHandleList_ = new(exCollHeap()) HashQueue(exCollHeap(), 50); // The 
hfsHandleList_ represents a list of distict hdfs Handles with unique hdfs port 
numbers and server names. Assume not more than 50 hdfsServers could be 
connected in the Trafodion setup.  These will get initialized the first time 
access is made to a particular hdfs server. This list gets cleaned up when the 
thread exits. 
--- End diff --

Can the literal 50 be a constant in a subsequent checkin?


> hdfsFS filesystem usage causies abnormal  behavior in Trafodion
> ---
>
> Key: TRAFODION-2091
> URL: https://issues.apache.org/jira/browse/TRAFODION-2091
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-general
>Affects Versions: 2.1-incubating
>Reporter: Sandhya Sundaresan
>Assignee: Sandhya Sundaresan
>
> Several components use the libhdfs API to perform operations on hdfs files in 
> Trafodion. Some places use the JNI API as well to access hdfs. 
> The inconsistency observed was ehen one component cached and kept the hdfsFS 
> hande for it's use another part of the code would perform a "close" or a 
> dsconnect and prematurely close the hdfsFS handle which is currently being 
> used. The reason is that the hdfs layer seems to cache the hdfsFS handle 
> underneathThe solution now is to keep a list of hdfsFS handles at the global 
> context level. All disconnect calls and JNI close calls are remmoved. The 
> hdfHS handles will get cleaned up either at context destructor time or at 
> endSession time. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (TRAFODION-2091) hdfsFS filesystem usage causies abnormal behavior in Trafodion

2016-07-05 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TRAFODION-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362521#comment-15362521
 ] 

ASF GitHub Bot commented on TRAFODION-2091:
---

Github user sureshsubbiah commented on a diff in the pull request:

https://github.com/apache/incubator-trafodion/pull/574#discussion_r69567539
  
--- Diff: core/sql/regress/hive/TEST005 ---
@@ -314,7 +314,7 @@ select a from hive.hive.thive;
 select * from hive.hive.thive;
 
 -- truncate of hive data
-cqd query_cache '0';
+--cqd query_cache '0';
--- End diff --

Glad that the test is being run with qcache ON now.


> hdfsFS filesystem usage causies abnormal  behavior in Trafodion
> ---
>
> Key: TRAFODION-2091
> URL: https://issues.apache.org/jira/browse/TRAFODION-2091
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-general
>Affects Versions: 2.1-incubating
>Reporter: Sandhya Sundaresan
>Assignee: Sandhya Sundaresan
>
> Several components use the libhdfs API to perform operations on hdfs files in 
> Trafodion. Some places use the JNI API as well to access hdfs. 
> The inconsistency observed was ehen one component cached and kept the hdfsFS 
> hande for it's use another part of the code would perform a "close" or a 
> dsconnect and prematurely close the hdfsFS handle which is currently being 
> used. The reason is that the hdfs layer seems to cache the hdfsFS handle 
> underneathThe solution now is to keep a list of hdfsFS handles at the global 
> context level. All disconnect calls and JNI close calls are remmoved. The 
> hdfHS handles will get cleaned up either at context destructor time or at 
> endSession time. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (TRAFODION-2091) hdfsFS filesystem usage causies abnormal behavior in Trafodion

2016-07-05 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TRAFODION-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362519#comment-15362519
 ] 

ASF GitHub Bot commented on TRAFODION-2091:
---

Github user sureshsubbiah commented on a diff in the pull request:

https://github.com/apache/incubator-trafodion/pull/574#discussion_r69567472
  
--- Diff: core/sql/src/main/java/org/trafodion/sql/HBulkLoadClient.java ---
@@ -475,10 +475,12 @@ public boolean release( ) throws IOException {
writer.close();
writer = null;
 }
-if (fileSys !=null)
+// sss This is one place that is unconditionally closing the 
--- End diff --

Should we remove "sss". It is a minor nit, and I know it is an oversight. 
Maybe this can be done in a subsequent checkin?


> hdfsFS filesystem usage causies abnormal  behavior in Trafodion
> ---
>
> Key: TRAFODION-2091
> URL: https://issues.apache.org/jira/browse/TRAFODION-2091
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-general
>Affects Versions: 2.1-incubating
>Reporter: Sandhya Sundaresan
>Assignee: Sandhya Sundaresan
>
> Several components use the libhdfs API to perform operations on hdfs files in 
> Trafodion. Some places use the JNI API as well to access hdfs. 
> The inconsistency observed was ehen one component cached and kept the hdfsFS 
> hande for it's use another part of the code would perform a "close" or a 
> dsconnect and prematurely close the hdfsFS handle which is currently being 
> used. The reason is that the hdfs layer seems to cache the hdfsFS handle 
> underneathThe solution now is to keep a list of hdfsFS handles at the global 
> context level. All disconnect calls and JNI close calls are remmoved. The 
> hdfHS handles will get cleaned up either at context destructor time or at 
> endSession time. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (TRAFODION-2034) Cannot output bad records in the loaded file even if specified file for storing bad records

2016-07-05 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TRAFODION-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362511#comment-15362511
 ] 

ASF GitHub Bot commented on TRAFODION-2034:
---

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-trafodion/pull/570


> Cannot output bad records in the loaded file even if specified file for 
> storing bad records
> ---
>
> Key: TRAFODION-2034
> URL: https://issues.apache.org/jira/browse/TRAFODION-2034
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: db-utility-odb
> Environment: centos6.7 HBase 1.0.0-cdh5.4.8
>Reporter: zhangliang
>Assignee: zhangliang
>Priority: Minor
>
> This issue is from mantis 330.
> Load file where is bad record in it, with option bad=output_data/bad_records 
> to hold the bad records, but the result is the file output_data/bad_records 
> generated but it is empty lines.
> [root@suse-1 odb_test]# ./odb64luo -u trafodion -p traf123 -d traf -l 
> src=output_data/ext_person3.csv:pre=@scripts/ddl_person3.sql:tgt=trafodion.odb_test.person3:max=1000:rows=5000:parallel=5:loadcmd=UL:fs=\|:sq=\":bad=output_data/bad_records
> odb [2016-04-25 19:17:05]: starting ODBC connection(s)... 0 1 2 3 4 5
> [0.0.0]Executing: 'drop table TRAFODION.odb_test.person3;'
> [0.0.0]--- command executed in 7.279s (prep 0.001s, exec 7.278s, fetch 
> 0.000s/0.000s)
> [0.0.1]Executing: 'CREATE TABLE TRAFODION.odb_test."PERSON3" (
> PID BIGINT SIGNED NOT NULL
> ,FNAME CHAR(20) NOT NULL
> ,LNAME CHAR(20) NOT NULL
> ,COUNTRY VARCHAR(40) NOT NULL
> ,CITY VARCHAR(40) NOT NULL
> ,BDATE DATE NOT NULL
> ,SEX CHAR(1) NOT NULL
> ,EMAIL VARCHAR(40) NOT NULL
> ,SALARY NUMERIC(9,2) NOT NULL
> ,EMPL VARCHAR(40) NOT NULL
> ,NOTES VARCHAR(80)
> ,LOADTS TIMESTAMP(0)
> ,PRIMARY KEY (PID)
> );'
> [0.0.1]--- command executed in 1.388s (prep 0.002s, exec 1.386s, fetch 
> 0.000s/0.000s)
> Connected to Trafodion
> [1] odb [Oloadbuff(9438)] - Error loading row 5 (State: 23000, Native 0)
> [Trafodion ODBC Driver] GENERAL ERROR. Null Value in a non nullable column. 
> Row: 5 Column: 1
> [1] 999 records inserted [commit]
> [0] odb version 1.1.0 Load statistics:
> [0] Target table: TRAFODION.ODB_TEST.PERSON3
> [0] Source: output_data/ext_person3.csv
> [0] Pre-loading time: 10.920 s (00:00:10.920)
> [0] Loading time: 0.127 s(00:00:00.127)
> [0] Total records read: 1,000
> [0] Total records inserted: 999
> [0] Total number of columns: 12
> [0] Total bytes read: 180,517
> [0] Average input row size: 180.5 B
> [0] ODBC row size: 341 B (data) + 96 B (len ind)
> [0] Rowset size: 1,000
> [0] Rowset buffer size: 426.76 KiB
> [0] Load throughput (real data): 1,388.080 KiB/s
> [0] Load throughput (ODBC): 2,619.487 KiB/s
> [0] Reader Total/Wait Cycles: 1/0
> odb [2016-04-25 19:17:16]: exiting. Session Elapsed time 11.060 seconds 
> (00:00:11.060)
> SQL>showddl person3;
>  
> CREATE TABLE TRAFODION.ODB_TEST.PERSON3
>   (
> PID LARGEINT NO DEFAULT NOT NULL NOT DROPPABLE
>   SERIALIZED
>   , FNAME CHAR(20) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , LNAME CHAR(20) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , COUNTRY VARCHAR(40) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , CITY VARCHAR(40) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , BDATE DATE NO DEFAULT NOT NULL NOT DROPPABLE NOT
>   SERIALIZED
>   , SEX CHAR(1) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , EMAIL VARCHAR(40) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , SALARY NUMERIC(9, 2) NO DEFAULT NOT NULL NOT
>   DROPPABLE SERIALIZED
>   , EMPL VARCHAR(40) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , NOTES VARCHAR(80) CHARACTER SET ISO88591 COLLATE
>   DEFAULT DEFAULT NULL SERIALIZED
>   , LOADTS TIMESTAMP(0) DEFAULT NULL NOT SERIALIZED
>   , PRIMARY KEY (PID ASC)
>   )
> ;
> --- SQL operation complete.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (TRAFODION-1609) Change swstatus to give a simple "up" or "down" answer, instead of the current, confusing display

2016-07-05 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TRAFODION-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362502#comment-15362502
 ] 

ASF GitHub Bot commented on TRAFODION-1609:
---

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-trafodion/pull/562


> Change swstatus to give a simple "up" or "down" answer, instead of the 
> current, confusing display
> -
>
> Key: TRAFODION-1609
> URL: https://issues.apache.org/jira/browse/TRAFODION-1609
> Project: Apache Trafodion
>  Issue Type: Improvement
>  Components: sql-general
>Reporter: Hans Zeller
>Assignee: Eason Zhang
>Priority: Minor
>
> The "swstatus" script used in cases where we did install_local_hadoop counts 
> the MySQL processes and then simply invokes jps.
> It would be better if the script would check specifically for HMaster, 
> NameNode, DataNode and maybe others, like NodeManager and ResourceManager. If 
> any are missing, it should print out which ones are missing, otherwise it 
> should just say something like "processes are up".
> It should also return an exit code of 0 if everything is up and 1 if some 
> processes are missing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (TRAFODION-1676) support better runtime error message when a SQL function meet fital error

2016-07-05 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TRAFODION-1676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15362491#comment-15362491
 ] 

ASF GitHub Bot commented on TRAFODION-1676:
---

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-trafodion/pull/564


> support better runtime error message when a SQL function meet fital error
> -
>
> Key: TRAFODION-1676
> URL: https://issues.apache.org/jira/browse/TRAFODION-1676
> Project: Apache Trafodion
>  Issue Type: Improvement
>  Components: sql-exe
>Reporter: liu ming
>Assignee: liu ming
>Priority: Minor
>
> A sql contains some SQL function, for example UPPER(), when the input data of 
> UPPER() contains invalid data, UPPER() will fail. In this case, the whole 
> query abort, and the error message cannot tell which row has invalid data, so 
> it is very hard to fix the problem.
> It will be good to have row id or the real value of the error row in the 
> error message to help trouble shooting.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (TRAFODION-2034) Cannot output bad records in the loaded file even if specified file for storing bad records

2016-07-05 Thread Jian Jin (JIRA)

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

Jian Jin updated TRAFODION-2034:

Assignee: zhangliang  (was: Jian Jin)

> Cannot output bad records in the loaded file even if specified file for 
> storing bad records
> ---
>
> Key: TRAFODION-2034
> URL: https://issues.apache.org/jira/browse/TRAFODION-2034
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: db-utility-odb
> Environment: centos6.7 HBase 1.0.0-cdh5.4.8
>Reporter: zhangliang
>Assignee: zhangliang
>Priority: Minor
>
> This issue is from mantis 330.
> Load file where is bad record in it, with option bad=output_data/bad_records 
> to hold the bad records, but the result is the file output_data/bad_records 
> generated but it is empty lines.
> [root@suse-1 odb_test]# ./odb64luo -u trafodion -p traf123 -d traf -l 
> src=output_data/ext_person3.csv:pre=@scripts/ddl_person3.sql:tgt=trafodion.odb_test.person3:max=1000:rows=5000:parallel=5:loadcmd=UL:fs=\|:sq=\":bad=output_data/bad_records
> odb [2016-04-25 19:17:05]: starting ODBC connection(s)... 0 1 2 3 4 5
> [0.0.0]Executing: 'drop table TRAFODION.odb_test.person3;'
> [0.0.0]--- command executed in 7.279s (prep 0.001s, exec 7.278s, fetch 
> 0.000s/0.000s)
> [0.0.1]Executing: 'CREATE TABLE TRAFODION.odb_test."PERSON3" (
> PID BIGINT SIGNED NOT NULL
> ,FNAME CHAR(20) NOT NULL
> ,LNAME CHAR(20) NOT NULL
> ,COUNTRY VARCHAR(40) NOT NULL
> ,CITY VARCHAR(40) NOT NULL
> ,BDATE DATE NOT NULL
> ,SEX CHAR(1) NOT NULL
> ,EMAIL VARCHAR(40) NOT NULL
> ,SALARY NUMERIC(9,2) NOT NULL
> ,EMPL VARCHAR(40) NOT NULL
> ,NOTES VARCHAR(80)
> ,LOADTS TIMESTAMP(0)
> ,PRIMARY KEY (PID)
> );'
> [0.0.1]--- command executed in 1.388s (prep 0.002s, exec 1.386s, fetch 
> 0.000s/0.000s)
> Connected to Trafodion
> [1] odb [Oloadbuff(9438)] - Error loading row 5 (State: 23000, Native 0)
> [Trafodion ODBC Driver] GENERAL ERROR. Null Value in a non nullable column. 
> Row: 5 Column: 1
> [1] 999 records inserted [commit]
> [0] odb version 1.1.0 Load statistics:
> [0] Target table: TRAFODION.ODB_TEST.PERSON3
> [0] Source: output_data/ext_person3.csv
> [0] Pre-loading time: 10.920 s (00:00:10.920)
> [0] Loading time: 0.127 s(00:00:00.127)
> [0] Total records read: 1,000
> [0] Total records inserted: 999
> [0] Total number of columns: 12
> [0] Total bytes read: 180,517
> [0] Average input row size: 180.5 B
> [0] ODBC row size: 341 B (data) + 96 B (len ind)
> [0] Rowset size: 1,000
> [0] Rowset buffer size: 426.76 KiB
> [0] Load throughput (real data): 1,388.080 KiB/s
> [0] Load throughput (ODBC): 2,619.487 KiB/s
> [0] Reader Total/Wait Cycles: 1/0
> odb [2016-04-25 19:17:16]: exiting. Session Elapsed time 11.060 seconds 
> (00:00:11.060)
> SQL>showddl person3;
>  
> CREATE TABLE TRAFODION.ODB_TEST.PERSON3
>   (
> PID LARGEINT NO DEFAULT NOT NULL NOT DROPPABLE
>   SERIALIZED
>   , FNAME CHAR(20) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , LNAME CHAR(20) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , COUNTRY VARCHAR(40) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , CITY VARCHAR(40) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , BDATE DATE NO DEFAULT NOT NULL NOT DROPPABLE NOT
>   SERIALIZED
>   , SEX CHAR(1) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , EMAIL VARCHAR(40) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , SALARY NUMERIC(9, 2) NO DEFAULT NOT NULL NOT
>   DROPPABLE SERIALIZED
>   , EMPL VARCHAR(40) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , NOTES VARCHAR(80) CHARACTER SET ISO88591 COLLATE
>   DEFAULT DEFAULT NULL SERIALIZED
>   , LOADTS TIMESTAMP(0) DEFAULT NULL NOT SERIALIZED
>   , PRIMARY KEY (PID ASC)
>   )
> ;
> --- SQL operation complete.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (TRAFODION-2034) Cannot output bad records in the loaded file even if specified file for storing bad records

2016-07-05 Thread Jian Jin (JIRA)

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

Jian Jin updated TRAFODION-2034:

Assignee: zhangliang

> Cannot output bad records in the loaded file even if specified file for 
> storing bad records
> ---
>
> Key: TRAFODION-2034
> URL: https://issues.apache.org/jira/browse/TRAFODION-2034
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: db-utility-odb
> Environment: centos6.7 HBase 1.0.0-cdh5.4.8
>Reporter: zhangliang
>Assignee: zhangliang
>Priority: Minor
>
> This issue is from mantis 330.
> Load file where is bad record in it, with option bad=output_data/bad_records 
> to hold the bad records, but the result is the file output_data/bad_records 
> generated but it is empty lines.
> [root@suse-1 odb_test]# ./odb64luo -u trafodion -p traf123 -d traf -l 
> src=output_data/ext_person3.csv:pre=@scripts/ddl_person3.sql:tgt=trafodion.odb_test.person3:max=1000:rows=5000:parallel=5:loadcmd=UL:fs=\|:sq=\":bad=output_data/bad_records
> odb [2016-04-25 19:17:05]: starting ODBC connection(s)... 0 1 2 3 4 5
> [0.0.0]Executing: 'drop table TRAFODION.odb_test.person3;'
> [0.0.0]--- command executed in 7.279s (prep 0.001s, exec 7.278s, fetch 
> 0.000s/0.000s)
> [0.0.1]Executing: 'CREATE TABLE TRAFODION.odb_test."PERSON3" (
> PID BIGINT SIGNED NOT NULL
> ,FNAME CHAR(20) NOT NULL
> ,LNAME CHAR(20) NOT NULL
> ,COUNTRY VARCHAR(40) NOT NULL
> ,CITY VARCHAR(40) NOT NULL
> ,BDATE DATE NOT NULL
> ,SEX CHAR(1) NOT NULL
> ,EMAIL VARCHAR(40) NOT NULL
> ,SALARY NUMERIC(9,2) NOT NULL
> ,EMPL VARCHAR(40) NOT NULL
> ,NOTES VARCHAR(80)
> ,LOADTS TIMESTAMP(0)
> ,PRIMARY KEY (PID)
> );'
> [0.0.1]--- command executed in 1.388s (prep 0.002s, exec 1.386s, fetch 
> 0.000s/0.000s)
> Connected to Trafodion
> [1] odb [Oloadbuff(9438)] - Error loading row 5 (State: 23000, Native 0)
> [Trafodion ODBC Driver] GENERAL ERROR. Null Value in a non nullable column. 
> Row: 5 Column: 1
> [1] 999 records inserted [commit]
> [0] odb version 1.1.0 Load statistics:
> [0] Target table: TRAFODION.ODB_TEST.PERSON3
> [0] Source: output_data/ext_person3.csv
> [0] Pre-loading time: 10.920 s (00:00:10.920)
> [0] Loading time: 0.127 s(00:00:00.127)
> [0] Total records read: 1,000
> [0] Total records inserted: 999
> [0] Total number of columns: 12
> [0] Total bytes read: 180,517
> [0] Average input row size: 180.5 B
> [0] ODBC row size: 341 B (data) + 96 B (len ind)
> [0] Rowset size: 1,000
> [0] Rowset buffer size: 426.76 KiB
> [0] Load throughput (real data): 1,388.080 KiB/s
> [0] Load throughput (ODBC): 2,619.487 KiB/s
> [0] Reader Total/Wait Cycles: 1/0
> odb [2016-04-25 19:17:16]: exiting. Session Elapsed time 11.060 seconds 
> (00:00:11.060)
> SQL>showddl person3;
>  
> CREATE TABLE TRAFODION.ODB_TEST.PERSON3
>   (
> PID LARGEINT NO DEFAULT NOT NULL NOT DROPPABLE
>   SERIALIZED
>   , FNAME CHAR(20) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , LNAME CHAR(20) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , COUNTRY VARCHAR(40) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , CITY VARCHAR(40) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , BDATE DATE NO DEFAULT NOT NULL NOT DROPPABLE NOT
>   SERIALIZED
>   , SEX CHAR(1) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , EMAIL VARCHAR(40) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , SALARY NUMERIC(9, 2) NO DEFAULT NOT NULL NOT
>   DROPPABLE SERIALIZED
>   , EMPL VARCHAR(40) CHARACTER SET ISO88591 COLLATE
>   DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED
>   , NOTES VARCHAR(80) CHARACTER SET ISO88591 COLLATE
>   DEFAULT DEFAULT NULL SERIALIZED
>   , LOADTS TIMESTAMP(0) DEFAULT NULL NOT SERIALIZED
>   , PRIMARY KEY (PID ASC)
>   )
> ;
> --- SQL operation complete.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (TRAFODION-1128) LP Bug: 1439779 - Internal error when load command is used on non-default schema

2016-07-05 Thread Jian Jin (JIRA)

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

Jian Jin resolved TRAFODION-1128.
-
Resolution: Fixed

> LP Bug: 1439779 - Internal error when load command is used on non-default 
> schema
> 
>
> Key: TRAFODION-1128
> URL: https://issues.apache.org/jira/browse/TRAFODION-1128
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-cmp
>Reporter: Suresh Subbiah
>Assignee: Kevin Xu
> Fix For: 2.1-incubating
>
>
> set schema sch ;
> >>load  into G_TPCH2X.customer1 select * from hive.hive.customer ;
> ..
> Task: LOAD Status: StartedObject: TRAFODION.G_TPCH2X.CUSTOMER1
> Task:  CLEANUP Status: StartedObject: TRAFODION.G_TPCH2X.CUSTOMER1
> Task:  CLEANUP Status: Ended  Object: TRAFODION.G_TPCH2X.CUSTOMER1
> Task:  DISABLE INDEXE  Status: StartedObject: TRAFODION.G_TPCH2X.CUSTOMER1
> *** ERROR[2006] Internal error: assertion failure (schemaNamePart == 
> currSchName) in file  at line -9.
> Problem is easy to reproduce and should happen with any table.  If the source 
> table is on a schema that is different from the current default schema then 
> this error is seen.
> It is interesting to note that the following statement does NOT raise this 
> error
>  >>load with no populate indexes into G_TPCH2X.customer1 select * from 
> hive.hive.customer ;
> Task: LOAD Status: StartedObject: TRAFODION.G_TPCH2X.CUSTOMER1
> Task:  CLEANUP Status: StartedObject: TRAFODION.G_TPCH2X.CUSTOMER1
> Task:  CLEANUP Status: Ended  Object: TRAFODION.G_TPCH2X.CUSTOMER1
> Task:  PREPARATION Status: StartedObject: TRAFODION.G_TPCH2X.CUSTOMER1
> 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)