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

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

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

    https://github.com/apache/incubator-trafodion/pull/218#discussion_r47161912
  
    --- Diff: core/sql/optimizer/GroupAttr.cpp ---
    @@ -327,6 +327,38 @@ void GroupAttributes::addConstraint(ItemExpr *c)
           }
           break;
     
    +    case ITM_CHECK_OPT_CONSTRAINT:
    +      {
    +        CheckOptConstraint *cc = (CheckOptConstraint *) c;
    +
    +        // check existing uniqueness constraints whether they are similar
    +        // and combine uniqueness constraints if possible
    +        for (ValueId occ = constraints_.init();
    +             constraints_.next(occ);
    +             constraints_.advance(occ))
    +          {
    +            if (occ.getItemExpr()->getOperatorType() ==
    +           ITM_CHECK_OPT_CONSTRAINT)
    +              {
    +                const ValueIdSet &occPreds =
    +                  ((CheckOptConstraint *) 
occ.getItemExpr())->getCheckPreds();
    +
    +                if (occPreds.contains(cc->getCheckPreds()))
    --- End diff --
    
    Sorry, just realize that below, the code may add the same check constraint 
multiple times, so we do need the simple guard against that. Therefore the 
check is not nearly useless, it's just not as smart as it could be.


> Add a TMUDF that can return a JDBC result set as table-valued output
> --------------------------------------------------------------------
>
>                 Key: TRAFODION-1581
>                 URL: https://issues.apache.org/jira/browse/TRAFODION-1581
>             Project: Apache Trafodion
>          Issue Type: Sub-task
>          Components: sql-general
>    Affects Versions: 1.3-incubating
>            Reporter: Hans Zeller
>            Assignee: Hans Zeller
>             Fix For: 2.0-incubating
>
>
> One way to read data from other data sources would be a Trafodion TMUDF that 
> takes a connection string, an SQL statement and other necessary info as an 
> input, connects to a JDBC data source, prepares the statement, and returns 
> the result set as a table-valued output. This would enable a basic connector 
> for many data sources, including Spark, Drill and Kafka.
> Specifically, I would like to add a "predefined" TMUDF to Trafodion that 
> takes the following parameters:
> 1. The name of a jar with a JDBC driver.
> 2. A connection string to use
> 3. The class name of the driver
> 4. A user id
> 5. A password
> 6. The type of processing to do (right now only one type is supported)
> 7. Info depending on the type.
> The first type of processing I would like to add is "source", and it does the 
> following: It accepts a list of SQL statements to execute. Only one of these 
> statements can return a result set. The data in the result set will be 
> returned as table-valued output.
> Future processing types could do a parallel select like ODB does or they 
> could insert into a table on the system identified by the JDBC driver info.
> All parameters need to be compile-time constants, so that the UDF can connect 
> to the data source at compile time and prepare the statement. Based on the 
> prepared statement, it will determine number, names and SQL types of the 
> column(s) of the table-valued result.



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

Reply via email to