[jira] [Commented] (TRAFODION-1856) Revoke - object and column privilege checks not integrated for constraints

2016-03-01 Thread ASF GitHub Bot (JIRA)

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

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

Github user asfgit closed the pull request at:

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


> Revoke - object and column privilege checks not integrated for constraints
> --
>
> Key: TRAFODION-1856
> URL: https://issues.apache.org/jira/browse/TRAFODION-1856
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-security
>Reporter: Roberta Marton
>Assignee: Roberta Marton
>
> Today, when revoking the object REFERENCES privilege, the revoke fails if 
> there
> are any RI constraints that require the privilege.  However, there may be 
> column
> level privileges that exist that would still allow the constraint to be 
> present.
> Conversely, when revoking column REFERENCES privilege, the revoke does not
> check to see if REFERENCES privilege has been granted at the object level.
> In fact, the revoke operation does not check for dependencies on constraints
> correctly.
> For example:
>  user1:
>   create table dept( dept_no int not null primary key, dept_name char(50));
>   grant references on table dept to user2;
>   grant references(dept_no) to user2;
>  user2:
>   create table empl(empl_no int not null primary key, dept_no int not null);
>   alter table empl add constraint empl_dept
> foreign key (dept_no) references dept;
> user1 should be able to "revoke references on table dept from user2"  because 
> user2 still has the references privileges on column dept_no.  Vice versa, 
> user1 
> should be able to "revoke references(dept_no) on dept from user2" because 
> user2 
> still has the references privilege on table dept.



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


[jira] [Commented] (TRAFODION-1798) Support Transactions for DDL statements

2016-03-01 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/incubator-trafodion/pull/346#discussion_r54662095
  
--- Diff: core/sql/sqlcomp/CmpSeabaseDDLcommon.cpp ---
@@ -8167,35 +8239,71 @@ short CmpSeabaseDDL::executeSeabaseDDL(DDLExpr * 
ddlExpr, ExprNode * ddlNode,
 }
 
   NABoolean startXn = TRUE;
-  if ((ddlExpr->dropHbase()) ||
-  (ddlExpr->purgedataHbase()) ||
-  (ddlExpr->initHbase()) ||
-  (ddlExpr->createMDViews()) ||
-  (ddlExpr->dropMDViews()) ||
-  (ddlExpr->initAuthorization()) ||
-  (ddlExpr->dropAuthorization()) ||
-  (ddlExpr->addSeqTable()) ||
-  (ddlExpr->createRepos()) ||
-  (ddlExpr->dropRepos()) ||
-  (ddlExpr->upgradeRepos()) ||
-  (ddlExpr->addSchemaObjects()) ||
-  (ddlExpr->updateVersion()) ||
-  ((ddlNode) &&
-  // TODO: When making ALTER TABLE/INDEX transactional, add cases here 
for them
-   ((ddlNode->getOperatorType() == DDL_DROP_SCHEMA) ||
-(ddlNode->getOperatorType() == DDL_CLEANUP_OBJECTS) ||
-(ddlNode->getOperatorType() == 
DDL_ALTER_TABLE_ADD_CONSTRAINT_PRIMARY_KEY) ||
-(ddlNode->getOperatorType() ==  
DDL_ALTER_TABLE_ALTER_COLUMN_SET_SG_OPTION) ||
-(ddlNode->getOperatorType() == DDL_CREATE_INDEX) ||
-(ddlNode->getOperatorType() == DDL_POPULATE_INDEX) ||
-(ddlNode->getOperatorType() == DDL_CREATE_TABLE) ||
-(ddlNode->getOperatorType() == DDL_ALTER_TABLE_DROP_COLUMN) ||
-(ddlNode->getOperatorType() == DDL_DROP_TABLE
+
+  // no DDL transactions.
+  if ((NOT ddlExpr->ddlXns()) &&
+  ((ddlExpr->dropHbase()) ||
+   (ddlExpr->purgedataHbase()) ||
+   (ddlExpr->initHbase()) ||
+   (ddlExpr->createMDViews()) ||
+   (ddlExpr->dropMDViews()) ||
+   (ddlExpr->initAuthorization()) ||
+   (ddlExpr->dropAuthorization()) ||
+   (ddlExpr->addSeqTable()) ||
+   (ddlExpr->createRepos()) ||
+   (ddlExpr->dropRepos()) ||
+   (ddlExpr->upgradeRepos()) ||
+   (ddlExpr->addSchemaObjects()) ||
+   (ddlExpr->updateVersion(
+{
+  // transaction will be started and commited in called methods.
+  startXn = FALSE;
+}
+  
+  // no DDL transactions
+  if (((ddlNode) && (ddlNode->castToStmtDDLNode()) &&
+   (NOT ddlNode->castToStmtDDLNode()->ddlXns())) &&
+  ((ddlNode->getOperatorType() == DDL_DROP_SCHEMA) ||
+   (ddlNode->getOperatorType() == DDL_CLEANUP_OBJECTS) ||
+   (ddlNode->getOperatorType() == 
DDL_ALTER_TABLE_ADD_CONSTRAINT_PRIMARY_KEY) ||
+   (ddlNode->getOperatorType() == 
DDL_ALTER_TABLE_ALTER_COLUMN_SET_SG_OPTION) ||
+   (ddlNode->getOperatorType() == DDL_CREATE_INDEX) ||
+   (ddlNode->getOperatorType() == DDL_POPULATE_INDEX) ||
+   (ddlNode->getOperatorType() == DDL_CREATE_TABLE) ||
+   (ddlNode->getOperatorType() == DDL_ALTER_TABLE_DROP_COLUMN) ||
+   (ddlNode->getOperatorType() == DDL_DROP_TABLE)))
+{
--- End diff --

Earlier I had asked about ALTER TABLE/INDEX ALTER HBASE_OPTIONS... maybe 
that one should be here too.


> Support Transactions for DDL statements
> ---
>
> Key: TRAFODION-1798
> URL: https://issues.apache.org/jira/browse/TRAFODION-1798
> Project: Apache Trafodion
>  Issue Type: New Feature
>Reporter: Prashanth Vasudev
>Assignee: Prashanth Vasudev
> Attachments: TransactionsDDL_Apache.pdf
>
>
> This work to support transaction for DDL operations started before Trafodion 
> became part of incubation as Apache Trafodion.  The initial link to the 
> blueprint is https://blueprints.launchpad.net/trafodion/+spec/dtm-ddl-support
> Some of the implementation to support this feature is already in code base, 
> however there are some more additional changes needed to support completely.
> Additional changes include:
> 0. Enable existing transactional DDL support in transaction manager. Also 
> enable corresponding regression test.
> 1. SQL executor changes to leverage transactional DDL support by transaction 
> manager.
> 2. Issue with simultaneous transactional update to the table followed by 
> drop. This manifests as a hang when a drop schema is performed.
> 3. Recovery in case of HA failure scenario.



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


[jira] [Commented] (TRAFODION-1798) Support Transactions for DDL statements

2016-03-01 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/incubator-trafodion/pull/346#discussion_r54661369
  
--- Diff: core/sql/parser/StmtDDLAlter.cpp ---
@@ -1971,6 +1971,17 @@ StmtDDLAlterTableAddColumn::synthesize()
 theColumn->traverseList(
  this,
  StmtDDLAlterTableAddColumn_visit);
+
+ElemDDLColDefArray ColDefArray = getColDefArray();
+ElemDDLColDef *pColDef = ColDefArray[0];
+if (NOT pColDef->getColumnFamily().isNull())
+  {
+//TEMPTEMP 
+// Currently, DTM doesnt handle add columns with an explicit 
+// column family as a transactional operation.
+// Do not use ddl xns until that bug is fixed.
+setDdlXns(FALSE);
+  }
--- End diff --

How about ALTER TABLE/INDEX ALTER HBASE_OPTIONS?


> Support Transactions for DDL statements
> ---
>
> Key: TRAFODION-1798
> URL: https://issues.apache.org/jira/browse/TRAFODION-1798
> Project: Apache Trafodion
>  Issue Type: New Feature
>Reporter: Prashanth Vasudev
>Assignee: Prashanth Vasudev
> Attachments: TransactionsDDL_Apache.pdf
>
>
> This work to support transaction for DDL operations started before Trafodion 
> became part of incubation as Apache Trafodion.  The initial link to the 
> blueprint is https://blueprints.launchpad.net/trafodion/+spec/dtm-ddl-support
> Some of the implementation to support this feature is already in code base, 
> however there are some more additional changes needed to support completely.
> Additional changes include:
> 0. Enable existing transactional DDL support in transaction manager. Also 
> enable corresponding regression test.
> 1. SQL executor changes to leverage transactional DDL support by transaction 
> manager.
> 2. Issue with simultaneous transactional update to the table followed by 
> drop. This manifests as a hang when a drop schema is performed.
> 3. Recovery in case of HA failure scenario.



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


[jira] [Commented] (TRAFODION-1798) Support Transactions for DDL statements

2016-03-01 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/incubator-trafodion/pull/346#discussion_r54660334
  
--- Diff: core/sql/executor/ExExeUtilGet.cpp ---
@@ -3173,6 +3149,21 @@ short ExExeUtilGetHbaseObjectsTcb::work()
   }
   break;
 
+case EVAL_EXPR_:
--- End diff --

This is a very nice feature. Thanks for adding this. I've always wondered 
though why GET statements aren't simply SELECTs. Would be nice to embed them 
within other SELECTs for example. There have been times when I've wanted to 
join them to other things too.


> Support Transactions for DDL statements
> ---
>
> Key: TRAFODION-1798
> URL: https://issues.apache.org/jira/browse/TRAFODION-1798
> Project: Apache Trafodion
>  Issue Type: New Feature
>Reporter: Prashanth Vasudev
>Assignee: Prashanth Vasudev
> Attachments: TransactionsDDL_Apache.pdf
>
>
> This work to support transaction for DDL operations started before Trafodion 
> became part of incubation as Apache Trafodion.  The initial link to the 
> blueprint is https://blueprints.launchpad.net/trafodion/+spec/dtm-ddl-support
> Some of the implementation to support this feature is already in code base, 
> however there are some more additional changes needed to support completely.
> Additional changes include:
> 0. Enable existing transactional DDL support in transaction manager. Also 
> enable corresponding regression test.
> 1. SQL executor changes to leverage transactional DDL support by transaction 
> manager.
> 2. Issue with simultaneous transactional update to the table followed by 
> drop. This manifests as a hang when a drop schema is performed.
> 3. Recovery in case of HA failure scenario.



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


[jira] [Commented] (TRAFODION-1798) Support Transactions for DDL statements

2016-03-01 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/incubator-trafodion/pull/346#discussion_r54659917
  
--- Diff: core/sql/cli/Context.h ---
@@ -472,6 +477,10 @@ class ContextCli : public ExGod {
   bool cbServerInUse_;
   NABoolean dropInProgress_;
 
+  // set to true if ddl stmts are issued.
+  // Reset at begin and commit Xn. Used to do NATable invalidation
+  // for ddl stmts issued within a transaction.
--- End diff --

Glad you are doing this. This has often been a sore point.


> Support Transactions for DDL statements
> ---
>
> Key: TRAFODION-1798
> URL: https://issues.apache.org/jira/browse/TRAFODION-1798
> Project: Apache Trafodion
>  Issue Type: New Feature
>Reporter: Prashanth Vasudev
>Assignee: Prashanth Vasudev
> Attachments: TransactionsDDL_Apache.pdf
>
>
> This work to support transaction for DDL operations started before Trafodion 
> became part of incubation as Apache Trafodion.  The initial link to the 
> blueprint is https://blueprints.launchpad.net/trafodion/+spec/dtm-ddl-support
> Some of the implementation to support this feature is already in code base, 
> however there are some more additional changes needed to support completely.
> Additional changes include:
> 0. Enable existing transactional DDL support in transaction manager. Also 
> enable corresponding regression test.
> 1. SQL executor changes to leverage transactional DDL support by transaction 
> manager.
> 2. Issue with simultaneous transactional update to the table followed by 
> drop. This manifests as a hang when a drop schema is performed.
> 3. Recovery in case of HA failure scenario.



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


[jira] [Commented] (TRAFODION-1798) Support Transactions for DDL statements

2016-03-01 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/incubator-trafodion/pull/346#discussion_r54652316
  
--- Diff: core/sql/executor/ex_transaction.cpp ---
@@ -1316,11 +1309,29 @@ short ExTransTcb::work()
   // create a diagsArea and return it to the parent.
   handleErrors(pentry_down, ta->getDiagsArea());
 
+if (cliGlobals->currContext()->ddlStmtsExecuted())
+  {
+ComDiagsArea * diagsArea = NULL;
+ExSqlComp::ReturnStatus cmpStatus = 
+  cliGlobals->currContext()->sendXnMsgToArkcmp
+  (NULL, 0,
+   EXSQLCOMP::DDL_NATABLE_INVALIDATE,
+   diagsArea);
+if (cmpStatus == ExSqlComp::ERROR)
+  {
+handleErrors(pentry_down, NULL, 
+ (ExeErrorCode)(-EXE_CANT_COMMIT_OR_ROLLBACK));
+ 
+return -1;
+  }
+  }
+
+cliGlobals->currContext()->ddlStmtsExecuted() = FALSE;
--- End diff --

The ddlStmtsExecuted flag will be set to TRUE if there is any error on 
commit or rollback. How can the user process recover from this,


> Support Transactions for DDL statements
> ---
>
> Key: TRAFODION-1798
> URL: https://issues.apache.org/jira/browse/TRAFODION-1798
> Project: Apache Trafodion
>  Issue Type: New Feature
>Reporter: Prashanth Vasudev
>Assignee: Prashanth Vasudev
> Attachments: TransactionsDDL_Apache.pdf
>
>
> This work to support transaction for DDL operations started before Trafodion 
> became part of incubation as Apache Trafodion.  The initial link to the 
> blueprint is https://blueprints.launchpad.net/trafodion/+spec/dtm-ddl-support
> Some of the implementation to support this feature is already in code base, 
> however there are some more additional changes needed to support completely.
> Additional changes include:
> 0. Enable existing transactional DDL support in transaction manager. Also 
> enable corresponding regression test.
> 1. SQL executor changes to leverage transactional DDL support by transaction 
> manager.
> 2. Issue with simultaneous transactional update to the table followed by 
> drop. This manifests as a hang when a drop schema is performed.
> 3. Recovery in case of HA failure scenario.



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


[jira] [Commented] (TRAFODION-1668) Cannot upload customer SPJ JARs

2016-03-01 Thread ASF GitHub Bot (JIRA)

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

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

Github user asfgit closed the pull request at:

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


> Cannot upload customer SPJ JARs
> ---
>
> Key: TRAFODION-1668
> URL: https://issues.apache.org/jira/browse/TRAFODION-1668
> Project: Apache Trafodion
>  Issue Type: Improvement
>Reporter: Kevin Xu
>Assignee: Kevin Xu
>




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


[jira] [Commented] (TRAFODION-1856) Revoke - object and column privilege checks not integrated for constraints

2016-03-01 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/incubator-trafodion/pull/349#discussion_r54640198
  
--- Diff: core/sql/sqlcomp/PrivMgrMD.cpp ---
@@ -962,29 +979,41 @@ PrivStatus 
PrivMgrMDAdmin::getReferencingTablesForConstraints (
 trafMetadataLocation_ + ".OBJECTS o";
   std::string tblConstraintsMDTable = 
 trafMetadataLocation_ + ".TABLE_CONSTRAINTS t";
+  std::string keysMDTable = 
+trafMetadataLocation_ + ".KEYS k";
   std::string uniqueRefConstraintsMDTable = 
 trafMetadataLocation_ + ".UNIQUE_REF_CONSTR_USAGE u";
 
   // Select all the constraints that are referenced by the table
-  // create_time is included to order by the oldest to newest
   std::string selectStmt = "select distinct o.object_uid, o.object_owner, 
o.object_type, o.create_time, ";
   selectStmt += "trim(o.catalog_name) || '.\"' || ";
-  selectStmt += "trim (o.schema_name) || '\".\"' ||";
-  selectStmt += "trim (o.object_name)|| '\"' from ";
+  selectStmt +=   "trim (o.schema_name) || '\".\"' ||";
+  selectStmt +=   "trim (o.object_name)|| '\"' ";
+  selectStmt += ", c.column_number "; 
+  selectStmt += "from " + uniqueRefConstraintsMDTable + std::string(", ");
--- End diff --

The "+" operator for the c++ string class does not allow char * to be 
appended. (At least I have been able to do so), but if it is converted to a 
string first, it works.  As far as how the malloc heap is used, probably 
depends on how the compiler generates the code. 


> Revoke - object and column privilege checks not integrated for constraints
> --
>
> Key: TRAFODION-1856
> URL: https://issues.apache.org/jira/browse/TRAFODION-1856
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-security
>Reporter: Roberta Marton
>Assignee: Roberta Marton
>
> Today, when revoking the object REFERENCES privilege, the revoke fails if 
> there
> are any RI constraints that require the privilege.  However, there may be 
> column
> level privileges that exist that would still allow the constraint to be 
> present.
> Conversely, when revoking column REFERENCES privilege, the revoke does not
> check to see if REFERENCES privilege has been granted at the object level.
> In fact, the revoke operation does not check for dependencies on constraints
> correctly.
> For example:
>  user1:
>   create table dept( dept_no int not null primary key, dept_name char(50));
>   grant references on table dept to user2;
>   grant references(dept_no) to user2;
>  user2:
>   create table empl(empl_no int not null primary key, dept_no int not null);
>   alter table empl add constraint empl_dept
> foreign key (dept_no) references dept;
> user1 should be able to "revoke references on table dept from user2"  because 
> user2 still has the references privileges on column dept_no.  Vice versa, 
> user1 
> should be able to "revoke references(dept_no) on dept from user2" because 
> user2 
> still has the references privilege on table dept.



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


[jira] [Commented] (TRAFODION-1856) Revoke - object and column privilege checks not integrated for constraints

2016-03-01 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/incubator-trafodion/pull/349#discussion_r54626149
  
--- Diff: core/sql/sqlcomp/PrivMgrMD.cpp ---
@@ -962,29 +979,41 @@ PrivStatus 
PrivMgrMDAdmin::getReferencingTablesForConstraints (
 trafMetadataLocation_ + ".OBJECTS o";
   std::string tblConstraintsMDTable = 
 trafMetadataLocation_ + ".TABLE_CONSTRAINTS t";
+  std::string keysMDTable = 
+trafMetadataLocation_ + ".KEYS k";
   std::string uniqueRefConstraintsMDTable = 
 trafMetadataLocation_ + ".UNIQUE_REF_CONSTR_USAGE u";
 
   // Select all the constraints that are referenced by the table
-  // create_time is included to order by the oldest to newest
   std::string selectStmt = "select distinct o.object_uid, o.object_owner, 
o.object_type, o.create_time, ";
   selectStmt += "trim(o.catalog_name) || '.\"' || ";
-  selectStmt += "trim (o.schema_name) || '\".\"' ||";
-  selectStmt += "trim (o.object_name)|| '\"' from ";
+  selectStmt +=   "trim (o.schema_name) || '\".\"' ||";
+  selectStmt +=   "trim (o.object_name)|| '\"' ";
+  selectStmt += ", c.column_number "; 
+  selectStmt += "from " + uniqueRefConstraintsMDTable + std::string(", ");
--- End diff --

Why is that ","  should be std::string?  I wonder if std::string will 
trigger memory allocation in the malloc heap space


> Revoke - object and column privilege checks not integrated for constraints
> --
>
> Key: TRAFODION-1856
> URL: https://issues.apache.org/jira/browse/TRAFODION-1856
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-security
>Reporter: Roberta Marton
>Assignee: Roberta Marton
>
> Today, when revoking the object REFERENCES privilege, the revoke fails if 
> there
> are any RI constraints that require the privilege.  However, there may be 
> column
> level privileges that exist that would still allow the constraint to be 
> present.
> Conversely, when revoking column REFERENCES privilege, the revoke does not
> check to see if REFERENCES privilege has been granted at the object level.
> In fact, the revoke operation does not check for dependencies on constraints
> correctly.
> For example:
>  user1:
>   create table dept( dept_no int not null primary key, dept_name char(50));
>   grant references on table dept to user2;
>   grant references(dept_no) to user2;
>  user2:
>   create table empl(empl_no int not null primary key, dept_no int not null);
>   alter table empl add constraint empl_dept
> foreign key (dept_no) references dept;
> user1 should be able to "revoke references on table dept from user2"  because 
> user2 still has the references privileges on column dept_no.  Vice versa, 
> user1 
> should be able to "revoke references(dept_no) on dept from user2" because 
> user2 
> still has the references privilege on table dept.



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


[jira] [Created] (TRAFODION-1864) LONGWVARCHAR column support have problems with storage of the column in hbase

2016-03-01 Thread Selvaganesan Govindarajan (JIRA)
Selvaganesan Govindarajan created TRAFODION-1864:


 Summary: LONGWVARCHAR column support have problems with storage of 
the column in hbase
 Key: TRAFODION-1864
 URL: https://issues.apache.org/jira/browse/TRAFODION-1864
 Project: Apache Trafodion
  Issue Type: Bug
  Components: sql-cmp, sql-exe
Reporter: Selvaganesan Govindarajan
 Fix For: 2.0-incubating


The LONGWVARCHAR is stored in hbase table as

xF26S0\xB4VP\xE3   column=#1:\x02, timestamp=1456841088934, 
value=\x00t\x00o\x00d\x00a\x00y\x00

But the omitted default value for this column would have 2 byte varchar 
indicator length prefix.

I would think how the LONGWVARCHAR is stored in hbase table might be wrong 
because it can't be null terminated.

The test case charsets/TEST012 now has a known diff file when this issue was 
exposed after merging PR 340



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


[jira] [Created] (TRAFODION-1863) With hbase_filter_preds set to '2', wrong results are returned for a specific use case.

2016-03-01 Thread Selvaganesan Govindarajan (JIRA)
Selvaganesan Govindarajan created TRAFODION-1863:


 Summary: With hbase_filter_preds set to '2', wrong results are 
returned for a specific use case.
 Key: TRAFODION-1863
 URL: https://issues.apache.org/jira/browse/TRAFODION-1863
 Project: Apache Trafodion
  Issue Type: Bug
Reporter: Selvaganesan Govindarajan


create table t056t57 (a1 numeric(2,2) signed default 0 not null);
showddl t056t57;
insert into t056t57 default values;
select * from t056t57;

>>select * from t056t57 ;

A1 
---

.00

--- 1 row(s) selected.
>>cqd hbase_filter_preds '2' ;

--- SQL operation complete.
>>select * from t056t57 ;
..

--- 0 row(s) selected.
>>

This was causing core/TEST056 to fail with PR #340.. Possibly similar issue is 
with core/TEST029 too,  Currently this test case runs with hbase_filter_preds 
set to 'ON'



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


[jira] [Commented] (TRAFODION-1836) License information for binary distribution of win-odbc

2016-03-01 Thread ASF GitHub Bot (JIRA)

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

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

Github user asfgit closed the pull request at:

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


> License information for binary distribution of win-odbc
> ---
>
> Key: TRAFODION-1836
> URL: https://issues.apache.org/jira/browse/TRAFODION-1836
> Project: Apache Trafodion
>  Issue Type: Sub-task
>  Components: client-odbc-windows
>Reporter: Steve Varnau
>Assignee: Weiqing Xu
>
> Gather license information for any software bundled into the win-odbc build 
> and packaged with other trafodion clients



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


[jira] [Created] (TRAFODION-1862) Transaction ID is returned as -1 when using the in memory table for RMS stats

2016-03-01 Thread Venkat Muthuswamy (JIRA)
Venkat Muthuswamy created TRAFODION-1862:


 Summary: Transaction ID is returned as -1 when using the in memory 
table for RMS stats
 Key: TRAFODION-1862
 URL: https://issues.apache.org/jira/browse/TRAFODION-1862
 Project: Apache Trafodion
  Issue Type: Bug
Reporter: Venkat Muthuswamy


When a query is executed under transaction, the transaction ID is part of the 
run time statistics.

The command "get statistics for qid " returns a valid transaction id.

However the command "Select * from table(statistics(null, 'QID='))" 
returns the transId as -1.





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


[jira] [Resolved] (TRAFODION-908) LP Bug: 1412640 - udf-event_log_reader: Select [first n] doesn’t work on workstation, it will return all records, but works fine on cluster

2016-03-01 Thread Hans Zeller (JIRA)

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

Hans Zeller resolved TRAFODION-908.
---
Resolution: Fixed

Fixed with https://github.com/apache/incubator-trafodion/pull/351

> LP Bug: 1412640 - udf-event_log_reader: Select [first n] doesn’t work on 
> workstation, it will return all records, but works fine on cluster
> ---
>
> Key: TRAFODION-908
> URL: https://issues.apache.org/jira/browse/TRAFODION-908
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-cmp
>Reporter: Gao, Rui-Xian
>Assignee: Hans Zeller
>Priority: Critical
> Fix For: 2.0-incubating
>
>
> Select [first n] doesn’t work on workstation, it will return all records. But 
> works fine on cluster.
> Try this statement on a cluster and workstation --
>  select [first 1] * from udf(event_log_reader('f')) where component='SQL' and 
> severity='ERROR';
> Result : 
> mapr1(cluster) – return 1 row
> sqws139 – return 2203 rows



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


[jira] [Resolved] (TRAFODION-1850) Select First N from TMUDF Select all rows

2016-03-01 Thread Hans Zeller (JIRA)

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

Hans Zeller resolved TRAFODION-1850.

   Resolution: Fixed
Fix Version/s: 2.0-incubating

> Select First N from TMUDF Select all rows
> -
>
> Key: TRAFODION-1850
> URL: https://issues.apache.org/jira/browse/TRAFODION-1850
> Project: Apache Trafodion
>  Issue Type: Bug
>Reporter: hazi goldman
>Assignee: Hans Zeller
> Fix For: 2.0-incubating
>
>
> If I use this with esp parallelism ON then First N is honored but with 
> parallelism OFF it returns all rows,
> select [first 10] * from udf(udfFooName(table(select * from logs)))



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


[jira] [Resolved] (TRAFODION-1847) Upsert with omitted timestamp columns having current_timestamp as default in a non-aligned format table returns wrong value for this column

2016-03-01 Thread Selvaganesan Govindarajan (JIRA)

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

Selvaganesan Govindarajan resolved TRAFODION-1847.
--
Resolution: Fixed

See https://github.com/apache/incubator-trafodion/pull/340 for details

> Upsert with omitted timestamp columns having current_timestamp as default in 
> a non-aligned format table returns wrong value for this column
> ---
>
> Key: TRAFODION-1847
> URL: https://issues.apache.org/jira/browse/TRAFODION-1847
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-cmp, sql-exe
>Affects Versions: 1.3-incubating
>Reporter: Selvaganesan Govindarajan
>Assignee: Selvaganesan Govindarajan
> Fix For: 2.0-incubating
>
>
> >>CREATE TABLE TRAFODION.SCH.HF_BUG
>   (
> ALARGEINT NO DEFAULT NOT NULL NOT 
> DROPPABLE
>   SERIALIZED
>   , BCHAR(10) CHARACTER SET ISO88591 COLLATE
>   DEFAULT DEFAULT NULL SERIALIZED
>   , CTIMESTAMP(6) DEFAULT CURRENT NOT
>   SERIALIZED
>   , DINT DEFAULT NULL SERIALIZED
>   , EINT DEFAULT 3 SERIALIZED
>   , PRIMARY KEY (A ASC)
>   )
> ;
> upsert into sch.hf_bug (a,b) values (4,'a') ;
> select * from sch.hf_bug ;
> >>upsert into sch.hf_bug (a,b) values (4,'a') ;
> --- 1 row(s) inserted.
> >>select * from hf_bug ;
> A B   C   DE
>   --  --  ---  
> ---
>4  a   0001-01-01 12:00:00.00? 
>3
> --- 1 row(s) selected.



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


[jira] [Resolved] (TRAFODION-1700) Upsert with omitted default value columns leave the aligned format table in corrupted state.

2016-03-01 Thread Selvaganesan Govindarajan (JIRA)

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

Selvaganesan Govindarajan resolved TRAFODION-1700.
--
   Resolution: Fixed
Fix Version/s: 2.0-incubating

See https://github.com/apache/incubator-trafodion/pull/340 for details

> Upsert with omitted default value columns leave the aligned format table in 
> corrupted state.
> 
>
> Key: TRAFODION-1700
> URL: https://issues.apache.org/jira/browse/TRAFODION-1700
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-general
>Affects Versions: 2.0-incubating
>Reporter: Suresh Subbiah
>Assignee: Selvaganesan Govindarajan
> Fix For: 2.0-incubating
>
>
> Please use this to reproduce the problem
> CREATE TABLE al_bug
>   (
> a LARGEINT GENERATED BY DEFAULT AS IDENTITY
>   , b LARGEINT DEFAULT NULL
>   , c TIMESTAMP(6) DEFAULT CURRENT
>   , d TIMESTAMP(6) DEFAULT CURRENT
>   , e SMALLINT DEFAULT NULL SERIALIZED
>   , f VARCHAR(10 BYTES) CHARACTER SET UTF8 DEFAULT NULL
>   , primary key (a))
>   salt using 2 partitions
>   attributes aligned format ;
> upsert into al_bug(b,f) select * from (values(1,'a'),(2,'b'),(3,'c')) x ;
> >>select * from al_bug ;
> ..
> A B C   D 
>   E   F
>     --  
> --  --  --
>1 1 97- 00:00:00.425344
>  00:00:00.00   1
>2 2 98- 00:00:00.425344
>  00:00:00.00   1
>3 3 99- 00:00:00.425344
>  00:00:00.00   1
> --- 3 row(s) selected.
> >>
> Columns C, D have wrong values here and likely E & F too.
> If F is declared as VARCHAR(4K) more junk characters can be seen  in output.
> These similar table definitions do not seem to have the problem
> create table al_bug (a int default null, b int ) attributes aligned format ;
> create table al_bug3 (a0 largeint generated by default as identity, a 
> timestamp default current, e int default null, b varchar(10), primary key(a0) 
> ) attributes aligned format ;



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


[jira] [Commented] (TRAFODION-1700) Upsert with omitted default value columns leave the aligned format table in corrupted state.

2016-03-01 Thread ASF GitHub Bot (JIRA)

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

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

Github user asfgit closed the pull request at:

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


> Upsert with omitted default value columns leave the aligned format table in 
> corrupted state.
> 
>
> Key: TRAFODION-1700
> URL: https://issues.apache.org/jira/browse/TRAFODION-1700
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-general
>Affects Versions: 2.0-incubating
>Reporter: Suresh Subbiah
>Assignee: Selvaganesan Govindarajan
>
> Please use this to reproduce the problem
> CREATE TABLE al_bug
>   (
> a LARGEINT GENERATED BY DEFAULT AS IDENTITY
>   , b LARGEINT DEFAULT NULL
>   , c TIMESTAMP(6) DEFAULT CURRENT
>   , d TIMESTAMP(6) DEFAULT CURRENT
>   , e SMALLINT DEFAULT NULL SERIALIZED
>   , f VARCHAR(10 BYTES) CHARACTER SET UTF8 DEFAULT NULL
>   , primary key (a))
>   salt using 2 partitions
>   attributes aligned format ;
> upsert into al_bug(b,f) select * from (values(1,'a'),(2,'b'),(3,'c')) x ;
> >>select * from al_bug ;
> ..
> A B C   D 
>   E   F
>     --  
> --  --  --
>1 1 97- 00:00:00.425344
>  00:00:00.00   1
>2 2 98- 00:00:00.425344
>  00:00:00.00   1
>3 3 99- 00:00:00.425344
>  00:00:00.00   1
> --- 3 row(s) selected.
> >>
> Columns C, D have wrong values here and likely E & F too.
> If F is declared as VARCHAR(4K) more junk characters can be seen  in output.
> These similar table definitions do not seem to have the problem
> create table al_bug (a int default null, b int ) attributes aligned format ;
> create table al_bug3 (a0 largeint generated by default as identity, a 
> timestamp default current, e int default null, b varchar(10), primary key(a0) 
> ) attributes aligned format ;



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


[jira] [Commented] (TRAFODION-1856) Revoke - object and column privilege checks not integrated for constraints

2016-03-01 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/incubator-trafodion/pull/349#discussion_r54603261
  
--- Diff: core/sql/sqlcomp/PrivMgrMD.h ---
@@ -110,12 +106,35 @@ typedef struct {
 
 } ViewUsage;
 
-typedef struct {
+// ---
+// Class definitions
+// ---
+class ObjectReference
+{
+  public:
+
+  ObjectReference()
+  : objectUID(0),
+objectOwner(NA_UserIdDefault),
+objectType(COM_UNKNOWN_OBJECT),
+columnReferences(NULL),
+updatedPrivs()
+  {}
+
+  virtual ~ObjectReference ( void )
+  {
+while(!columnReferences->empty())
+  delete columnReferences->back(), columnReferences->pop_back();
--- End diff --

I did look this up, and it should be equivalent in this case,  the comma 
does not end the statement. It is part of a longer statement which ends with a 
semi-colon. It does the same thing as calling functions as separate statements.



> Revoke - object and column privilege checks not integrated for constraints
> --
>
> Key: TRAFODION-1856
> URL: https://issues.apache.org/jira/browse/TRAFODION-1856
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-security
>Reporter: Roberta Marton
>Assignee: Roberta Marton
>
> Today, when revoking the object REFERENCES privilege, the revoke fails if 
> there
> are any RI constraints that require the privilege.  However, there may be 
> column
> level privileges that exist that would still allow the constraint to be 
> present.
> Conversely, when revoking column REFERENCES privilege, the revoke does not
> check to see if REFERENCES privilege has been granted at the object level.
> In fact, the revoke operation does not check for dependencies on constraints
> correctly.
> For example:
>  user1:
>   create table dept( dept_no int not null primary key, dept_name char(50));
>   grant references on table dept to user2;
>   grant references(dept_no) to user2;
>  user2:
>   create table empl(empl_no int not null primary key, dept_no int not null);
>   alter table empl add constraint empl_dept
> foreign key (dept_no) references dept;
> user1 should be able to "revoke references on table dept from user2"  because 
> user2 still has the references privileges on column dept_no.  Vice versa, 
> user1 
> should be able to "revoke references(dept_no) on dept from user2" because 
> user2 
> still has the references privilege on table dept.



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


[jira] [Closed] (TRAFODION-1522) Consolidate HBase version requirements in Trafodion build

2016-03-01 Thread Steve Varnau (JIRA)

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

Steve Varnau closed TRAFODION-1522.
---
   Resolution: Fixed
Fix Version/s: 2.0-incubating

> Consolidate HBase version requirements in Trafodion build
> -
>
> Key: TRAFODION-1522
> URL: https://issues.apache.org/jira/browse/TRAFODION-1522
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-general
>Affects Versions: 1.1 (pre-incubation)
> Environment: Any
>Reporter: Hans Zeller
>Assignee: Steve Varnau
> Fix For: 2.0-incubating
>
>
> With our recent changes (e.g. TRAFODION-1521), we are getting to a point 
> where all of our HBase dependencies are coded in the build files, rather than 
> relying on some installation of HBase.
> As a next step, we should consolidate those dependencies and record them in 
> only one place, if possible.
> A possible solution would be a Maven project hierarchy, with the top-level 
> Maven project file defining the hbase.version project property as well as 
> related properties like Hive, Thrift, and other dependencies.
> Here is a list of places where we have such required versions today (HBase 
> refers to 0.98.1-cdh5.1.0 unless specified otherwise):
> core/sql/pom.xml (HBase, HBase-trx, Hive 0.13.1, Thrift 0.9.0, Java 1.7)
> core/sqf/src/seatrans/tm/hbasetmlib2/pom.xml (HBase)
> core/sqf/src/seatrans/hbase-trx/pom.xml (HBase)
> core/sqf/src/seatrans/hbase-trx/hbase-protocol/pom.xml (HBase 0.98.3)
> core/sqf/sql/scripts/get_libhdfs_files (HBase)
> core/sqf/sql/scripts/install_local_hadoop (hbase-0.98.6-cdh5.3.0, 
> hadoop-2.5.0-cdh5.3.0, Hive 0.13.1)
> Also, we could try to streamline protobuf dependencies, some components 
> (coprocessors, get_libhdfs_files) depend on protobuf 2.5.0, which is also 
> used in some Maven pom.xml files.



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


[jira] [Commented] (TRAFODION-1857) Unable to connect to Zookeeper over time

2016-03-01 Thread ASF GitHub Bot (JIRA)

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

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

Github user asfgit closed the pull request at:

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


> Unable to connect to Zookeeper over time
> 
>
> Key: TRAFODION-1857
> URL: https://issues.apache.org/jira/browse/TRAFODION-1857
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: dtm
>Affects Versions: 2.0-incubating
>Reporter: Sean Broeder
>Assignee: Sean Broeder
> Fix For: 2.0-incubating
>
>
> HMASTER process has more than 1000 socket connections in CLOSE_WAIT.  Looks 
> like the the TLOG is creating and closing too many connections.



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


[jira] [Commented] (TRAFODION-1522) Consolidate HBase version requirements in Trafodion build

2016-03-01 Thread ASF GitHub Bot (JIRA)

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

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

Github user asfgit closed the pull request at:

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


> Consolidate HBase version requirements in Trafodion build
> -
>
> Key: TRAFODION-1522
> URL: https://issues.apache.org/jira/browse/TRAFODION-1522
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-general
>Affects Versions: 1.1 (pre-incubation)
> Environment: Any
>Reporter: Hans Zeller
>Assignee: Steve Varnau
>
> With our recent changes (e.g. TRAFODION-1521), we are getting to a point 
> where all of our HBase dependencies are coded in the build files, rather than 
> relying on some installation of HBase.
> As a next step, we should consolidate those dependencies and record them in 
> only one place, if possible.
> A possible solution would be a Maven project hierarchy, with the top-level 
> Maven project file defining the hbase.version project property as well as 
> related properties like Hive, Thrift, and other dependencies.
> Here is a list of places where we have such required versions today (HBase 
> refers to 0.98.1-cdh5.1.0 unless specified otherwise):
> core/sql/pom.xml (HBase, HBase-trx, Hive 0.13.1, Thrift 0.9.0, Java 1.7)
> core/sqf/src/seatrans/tm/hbasetmlib2/pom.xml (HBase)
> core/sqf/src/seatrans/hbase-trx/pom.xml (HBase)
> core/sqf/src/seatrans/hbase-trx/hbase-protocol/pom.xml (HBase 0.98.3)
> core/sqf/sql/scripts/get_libhdfs_files (HBase)
> core/sqf/sql/scripts/install_local_hadoop (hbase-0.98.6-cdh5.3.0, 
> hadoop-2.5.0-cdh5.3.0, Hive 0.13.1)
> Also, we could try to streamline protobuf dependencies, some components 
> (coprocessors, get_libhdfs_files) depend on protobuf 2.5.0, which is also 
> used in some Maven pom.xml files.



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


[jira] [Commented] (TRAFODION-1856) Revoke - object and column privilege checks not integrated for constraints

2016-03-01 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/incubator-trafodion/pull/349#discussion_r54594735
  
--- Diff: core/sql/sqlcomp/PrivMgrMD.h ---
@@ -110,12 +106,35 @@ typedef struct {
 
 } ViewUsage;
 
-typedef struct {
+// ---
+// Class definitions
+// ---
+class ObjectReference
+{
+  public:
+
+  ObjectReference()
+  : objectUID(0),
+objectOwner(NA_UserIdDefault),
+objectType(COM_UNKNOWN_OBJECT),
+columnReferences(NULL),
+updatedPrivs()
+  {}
+
+  virtual ~ObjectReference ( void )
+  {
+while(!columnReferences->empty())
+  delete columnReferences->back(), columnReferences->pop_back();
--- End diff --

Maybe I'm missing something. Isn't "delete columnReferences->back(), 
columnReferences->pop_back()" equivalent to { delete columnReferences->back(); 
columnReferences->pop_back(); }?


> Revoke - object and column privilege checks not integrated for constraints
> --
>
> Key: TRAFODION-1856
> URL: https://issues.apache.org/jira/browse/TRAFODION-1856
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-security
>Reporter: Roberta Marton
>Assignee: Roberta Marton
>
> Today, when revoking the object REFERENCES privilege, the revoke fails if 
> there
> are any RI constraints that require the privilege.  However, there may be 
> column
> level privileges that exist that would still allow the constraint to be 
> present.
> Conversely, when revoking column REFERENCES privilege, the revoke does not
> check to see if REFERENCES privilege has been granted at the object level.
> In fact, the revoke operation does not check for dependencies on constraints
> correctly.
> For example:
>  user1:
>   create table dept( dept_no int not null primary key, dept_name char(50));
>   grant references on table dept to user2;
>   grant references(dept_no) to user2;
>  user2:
>   create table empl(empl_no int not null primary key, dept_no int not null);
>   alter table empl add constraint empl_dept
> foreign key (dept_no) references dept;
> user1 should be able to "revoke references on table dept from user2"  because 
> user2 still has the references privileges on column dept_no.  Vice versa, 
> user1 
> should be able to "revoke references(dept_no) on dept from user2" because 
> user2 
> still has the references privilege on table dept.



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


[jira] [Commented] (TRAFODION-1856) Revoke - object and column privilege checks not integrated for constraints

2016-03-01 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/incubator-trafodion/pull/349#discussion_r54586561
  
--- Diff: core/sql/sqlcomp/PrivMgrMD.h ---
@@ -130,7 +149,70 @@ typedef struct {
 details += to_string((long long int) objectOwner);
   }
 
-} ObjectReference;
+};
+
+class ObjectUsage
+{
+  public:
+
+  ObjectUsage()
+  : objectUID (0),
+granteeID (NA_UserIdDefault),
+grantorIsSystem(false),
+objectType (COM_UNKNOWN_OBJECT),
+columnReferences(NULL),
+originalPrivs(),
+updatedPrivs()
+  {}
+
+  virtual ~ObjectUsage ( void )
+  {
+if (columnReferences)
+{
+  while(!columnReferences->empty())
+delete columnReferences->back(), columnReferences->pop_back();
+  delete columnReferences;
+}
+  }
+
+  int64_t objectUID;
+  int32_t granteeID;
+  bool grantorIsSystem;
+  std::string objectName;
+  ComObjectType objectType;
+  std::vector *columnReferences;
+  PrivMgrDesc originalPrivs;
+  PrivMgrDesc updatedPrivs;
+
+  ColumnReference * findColumn (int32_t columnOrdinal)
+  {
+if (columnReferences == NULL)
+  return NULL;
+for (int i = 0; i < columnReferences->size(); i++)
+{
+  ColumnReference *pRef = (*columnReferences)[i];
+  if (pRef->columnOrdinal == columnOrdinal)
--- End diff --

I will note this and look at it for a subsequent commit.


> Revoke - object and column privilege checks not integrated for constraints
> --
>
> Key: TRAFODION-1856
> URL: https://issues.apache.org/jira/browse/TRAFODION-1856
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-security
>Reporter: Roberta Marton
>Assignee: Roberta Marton
>
> Today, when revoking the object REFERENCES privilege, the revoke fails if 
> there
> are any RI constraints that require the privilege.  However, there may be 
> column
> level privileges that exist that would still allow the constraint to be 
> present.
> Conversely, when revoking column REFERENCES privilege, the revoke does not
> check to see if REFERENCES privilege has been granted at the object level.
> In fact, the revoke operation does not check for dependencies on constraints
> correctly.
> For example:
>  user1:
>   create table dept( dept_no int not null primary key, dept_name char(50));
>   grant references on table dept to user2;
>   grant references(dept_no) to user2;
>  user2:
>   create table empl(empl_no int not null primary key, dept_no int not null);
>   alter table empl add constraint empl_dept
> foreign key (dept_no) references dept;
> user1 should be able to "revoke references on table dept from user2"  because 
> user2 still has the references privileges on column dept_no.  Vice versa, 
> user1 
> should be able to "revoke references(dept_no) on dept from user2" because 
> user2 
> still has the references privilege on table dept.



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


[jira] [Commented] (TRAFODION-1856) Revoke - object and column privilege checks not integrated for constraints

2016-03-01 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/incubator-trafodion/pull/349#discussion_r54586211
  
--- Diff: core/sql/sqlcomp/PrivMgrMD.h ---
@@ -110,12 +106,35 @@ typedef struct {
 
 } ViewUsage;
 
-typedef struct {
+// ---
+// Class definitions
+// ---
+class ObjectReference
+{
+  public:
+
+  ObjectReference()
+  : objectUID(0),
+objectOwner(NA_UserIdDefault),
+objectType(COM_UNKNOWN_OBJECT),
+columnReferences(NULL),
+updatedPrivs()
+  {}
+
+  virtual ~ObjectReference ( void )
+  {
+while(!columnReferences->empty())
+  delete columnReferences->back(), columnReferences->pop_back();
--- End diff --

I was having issues getting this code to work and I searched the web for 
examples.  This was one suggestion and it worked.


> Revoke - object and column privilege checks not integrated for constraints
> --
>
> Key: TRAFODION-1856
> URL: https://issues.apache.org/jira/browse/TRAFODION-1856
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-security
>Reporter: Roberta Marton
>Assignee: Roberta Marton
>
> Today, when revoking the object REFERENCES privilege, the revoke fails if 
> there
> are any RI constraints that require the privilege.  However, there may be 
> column
> level privileges that exist that would still allow the constraint to be 
> present.
> Conversely, when revoking column REFERENCES privilege, the revoke does not
> check to see if REFERENCES privilege has been granted at the object level.
> In fact, the revoke operation does not check for dependencies on constraints
> correctly.
> For example:
>  user1:
>   create table dept( dept_no int not null primary key, dept_name char(50));
>   grant references on table dept to user2;
>   grant references(dept_no) to user2;
>  user2:
>   create table empl(empl_no int not null primary key, dept_no int not null);
>   alter table empl add constraint empl_dept
> foreign key (dept_no) references dept;
> user1 should be able to "revoke references on table dept from user2"  because 
> user2 still has the references privileges on column dept_no.  Vice versa, 
> user1 
> should be able to "revoke references(dept_no) on dept from user2" because 
> user2 
> still has the references privilege on table dept.



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


[jira] [Commented] (TRAFODION-1856) Revoke - object and column privilege checks not integrated for constraints

2016-03-01 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/incubator-trafodion/pull/349#discussion_r54585913
  
--- Diff: core/sql/sqlcomp/PrivMgrMD.h ---
@@ -110,12 +106,35 @@ typedef struct {
 
 } ViewUsage;
 
-typedef struct {
+// ---
+// Class definitions
+// ---
+class ObjectReference
+{
+  public:
+
+  ObjectReference()
+  : objectUID(0),
+objectOwner(NA_UserIdDefault),
+objectType(COM_UNKNOWN_OBJECT),
+columnReferences(NULL),
+updatedPrivs()
+  {}
+
+  virtual ~ObjectReference ( void )
+  {
+while(!columnReferences->empty())
--- End diff --

Will fix this.


> Revoke - object and column privilege checks not integrated for constraints
> --
>
> Key: TRAFODION-1856
> URL: https://issues.apache.org/jira/browse/TRAFODION-1856
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-security
>Reporter: Roberta Marton
>Assignee: Roberta Marton
>
> Today, when revoking the object REFERENCES privilege, the revoke fails if 
> there
> are any RI constraints that require the privilege.  However, there may be 
> column
> level privileges that exist that would still allow the constraint to be 
> present.
> Conversely, when revoking column REFERENCES privilege, the revoke does not
> check to see if REFERENCES privilege has been granted at the object level.
> In fact, the revoke operation does not check for dependencies on constraints
> correctly.
> For example:
>  user1:
>   create table dept( dept_no int not null primary key, dept_name char(50));
>   grant references on table dept to user2;
>   grant references(dept_no) to user2;
>  user2:
>   create table empl(empl_no int not null primary key, dept_no int not null);
>   alter table empl add constraint empl_dept
> foreign key (dept_no) references dept;
> user1 should be able to "revoke references on table dept from user2"  because 
> user2 still has the references privileges on column dept_no.  Vice versa, 
> user1 
> should be able to "revoke references(dept_no) on dept from user2" because 
> user2 
> still has the references privilege on table dept.



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


[jira] [Commented] (TRAFODION-1856) Revoke - object and column privilege checks not integrated for constraints

2016-03-01 Thread ASF GitHub Bot (JIRA)

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

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

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

https://github.com/apache/incubator-trafodion/pull/349#discussion_r54584974
  
--- Diff: core/sql/sqlcomp/CmpSeabaseDDLtable.cpp ---
@@ -6309,6 +6304,23 @@ void CmpSeabaseDDL::alterSeabaseTableAddRIConstraint(
   
   return;
 }
+
+   // If the user/role does not have REFERENCES privilege at the 
object 
+   // level, check to see if the user/role has been granted the 
privilege 
+   // on all affected columns
+   if (noObjPriv)
+ {
+   PrivMgrUserPrivs* privs = refdNaTable->getPrivInfo();
+   if (!privs->hasColReferencePriv(refdNAC->getPosition()))
+ {
+*CmpCommon::diags() << DgSqlCode(-4481)
--- End diff --

No, there are no enums for this range that I could find.


> Revoke - object and column privilege checks not integrated for constraints
> --
>
> Key: TRAFODION-1856
> URL: https://issues.apache.org/jira/browse/TRAFODION-1856
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-security
>Reporter: Roberta Marton
>Assignee: Roberta Marton
>
> Today, when revoking the object REFERENCES privilege, the revoke fails if 
> there
> are any RI constraints that require the privilege.  However, there may be 
> column
> level privileges that exist that would still allow the constraint to be 
> present.
> Conversely, when revoking column REFERENCES privilege, the revoke does not
> check to see if REFERENCES privilege has been granted at the object level.
> In fact, the revoke operation does not check for dependencies on constraints
> correctly.
> For example:
>  user1:
>   create table dept( dept_no int not null primary key, dept_name char(50));
>   grant references on table dept to user2;
>   grant references(dept_no) to user2;
>  user2:
>   create table empl(empl_no int not null primary key, dept_no int not null);
>   alter table empl add constraint empl_dept
> foreign key (dept_no) references dept;
> user1 should be able to "revoke references on table dept from user2"  because 
> user2 still has the references privileges on column dept_no.  Vice versa, 
> user1 
> should be able to "revoke references(dept_no) on dept from user2" because 
> user2 
> still has the references privilege on table dept.



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


[jira] [Created] (TRAFODION-1861) support Trafodion running on CentOS 7

2016-03-01 Thread liu ming (JIRA)
liu ming created TRAFODION-1861:
---

 Summary: support Trafodion running on CentOS 7
 Key: TRAFODION-1861
 URL: https://issues.apache.org/jira/browse/TRAFODION-1861
 Project: Apache Trafodion
  Issue Type: Umbrella
Reporter: liu ming






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