[JBoss JIRA] (TEIID-3674) NOT IN construct behaves inconsistently
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3674?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-3674:
----------------------------------
Fix Version/s: 8.11.4
> NOT IN construct behaves inconsistently
> ---------------------------------------
>
> Key: TEIID-3674
> URL: https://issues.jboss.org/browse/TEIID-3674
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.0
> Reporter: Salvatore R
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 8.12, 8.11.4
>
>
> As discussed in https://developer.jboss.org/message/939309#939309, an inconsistent behavior of the NOT IN clause occurs when NULL values are returned by the subquery.
> For example, let us suppose to have a table defined as:
> {code:sql}
> CREATE TABLE test1 (col1 character varying(10));
> insert into test1 values ('a');
> insert into test1 values ('b');
> insert into test1 values ('c');
> insert into test1 values ('d');
> {code}
> If I enumerate values in the NOT IN clause and one of them is a NULL value:
> {code:sql}
> select * from pg.test1 where col1 NOT IN ('a', NULL, 'b');
> {code}
> the result is not empty (as it would be expected) but 'c' and 'd' are returned.
> Looking at the query plan, the NULL is wrongly removed from the list:
> {code:sql}
> ----------------------------------------------------------------------------
> OPTIMIZATION COMPLETE:
> PROCESSOR PLAN:
> AccessNode(0) output=[pg.test1.col1] SELECT g_0.col1 FROM pg.test1 AS g_0 WHERE g_0.col1 NOT IN ('a', 'b')
>
>
> ============================================================================
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (TEIID-3674) NOT IN construct behaves inconsistently
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3674?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-3674:
----------------------------------
Fix Version/s: 8.12
Priority: Critical (was: Major)
Affects Version/s: 8.0
> NOT IN construct behaves inconsistently
> ---------------------------------------
>
> Key: TEIID-3674
> URL: https://issues.jboss.org/browse/TEIID-3674
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.0
> Reporter: Salvatore R
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 8.12
>
>
> As discussed in https://developer.jboss.org/message/939309#939309, an inconsistent behavior of the NOT IN clause occurs when NULL values are returned by the subquery.
> For example, let us suppose to have a table defined as:
> {code:sql}
> CREATE TABLE test1 (col1 character varying(10));
> insert into test1 values ('a');
> insert into test1 values ('b');
> insert into test1 values ('c');
> insert into test1 values ('d');
> {code}
> If I enumerate values in the NOT IN clause and one of them is a NULL value:
> {code:sql}
> select * from pg.test1 where col1 NOT IN ('a', NULL, 'b');
> {code}
> the result is not empty (as it would be expected) but 'c' and 'd' are returned.
> Looking at the query plan, the NULL is wrongly removed from the list:
> {code:sql}
> ----------------------------------------------------------------------------
> OPTIMIZATION COMPLETE:
> PROCESSOR PLAN:
> AccessNode(0) output=[pg.test1.col1] SELECT g_0.col1 FROM pg.test1 AS g_0 WHERE g_0.col1 NOT IN ('a', 'b')
>
>
> ============================================================================
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (TEIID-3674) NOT IN construct behaves inconsistently
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3674?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-3674.
-----------------------------------
Resolution: Done
Corrected the queryrwriter to more broadly preserve the unknown truth value.
> NOT IN construct behaves inconsistently
> ---------------------------------------
>
> Key: TEIID-3674
> URL: https://issues.jboss.org/browse/TEIID-3674
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.0
> Reporter: Salvatore R
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 8.12
>
>
> As discussed in https://developer.jboss.org/message/939309#939309, an inconsistent behavior of the NOT IN clause occurs when NULL values are returned by the subquery.
> For example, let us suppose to have a table defined as:
> {code:sql}
> CREATE TABLE test1 (col1 character varying(10));
> insert into test1 values ('a');
> insert into test1 values ('b');
> insert into test1 values ('c');
> insert into test1 values ('d');
> {code}
> If I enumerate values in the NOT IN clause and one of them is a NULL value:
> {code:sql}
> select * from pg.test1 where col1 NOT IN ('a', NULL, 'b');
> {code}
> the result is not empty (as it would be expected) but 'c' and 'd' are returned.
> Looking at the query plan, the NULL is wrongly removed from the list:
> {code:sql}
> ----------------------------------------------------------------------------
> OPTIMIZATION COMPLETE:
> PROCESSOR PLAN:
> AccessNode(0) output=[pg.test1.col1] SELECT g_0.col1 FROM pg.test1 AS g_0 WHERE g_0.col1 NOT IN ('a', 'b')
>
>
> ============================================================================
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (TEIID-3674) NOT IN construct behaves inconsistently
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3674?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-3674:
----------------------------------
Component/s: Query Engine
> NOT IN construct behaves inconsistently
> ---------------------------------------
>
> Key: TEIID-3674
> URL: https://issues.jboss.org/browse/TEIID-3674
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.0
> Reporter: Salvatore R
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 8.12
>
>
> As discussed in https://developer.jboss.org/message/939309#939309, an inconsistent behavior of the NOT IN clause occurs when NULL values are returned by the subquery.
> For example, let us suppose to have a table defined as:
> {code:sql}
> CREATE TABLE test1 (col1 character varying(10));
> insert into test1 values ('a');
> insert into test1 values ('b');
> insert into test1 values ('c');
> insert into test1 values ('d');
> {code}
> If I enumerate values in the NOT IN clause and one of them is a NULL value:
> {code:sql}
> select * from pg.test1 where col1 NOT IN ('a', NULL, 'b');
> {code}
> the result is not empty (as it would be expected) but 'c' and 'd' are returned.
> Looking at the query plan, the NULL is wrongly removed from the list:
> {code:sql}
> ----------------------------------------------------------------------------
> OPTIMIZATION COMPLETE:
> PROCESSOR PLAN:
> AccessNode(0) output=[pg.test1.col1] SELECT g_0.col1 FROM pg.test1 AS g_0 WHERE g_0.col1 NOT IN ('a', 'b')
>
>
> ============================================================================
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (TEIID-3682) Add logon properties to audit messages
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-3682:
-------------------------------------
Summary: Add logon properties to audit messages
Key: TEIID-3682
URL: https://issues.jboss.org/browse/TEIID-3682
Project: Teiid
Issue Type: Enhancement
Components: Query Engine
Affects Versions: 8.12
Reporter: Steven Hawkins
Assignee: Steven Hawkins
We expanded logon information in 8.12, but did not yet include all logon properties, which can include the client ip address - but there are limitations since the client ip and related fields would only be set for JDBC connections and not yet for local usage through ODBC/web.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (TEIID-3678) Unable to import native metada from HBase
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3678?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-3678.
-----------------------------------
Resolution: Done
Updated the executionfactory so that unique index info is not retrieved and so that import foreign keys defaults to false.
> Unable to import native metada from HBase
> -----------------------------------------
>
> Key: TEIID-3678
> URL: https://issues.jboss.org/browse/TEIID-3678
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.10, 8.7.1.6_2
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
> Fix For: 8.12
>
>
> Native metadata cloud not be imported if default values of import properties are used:
> {code:xml}
> <vdb name="hbase_test_vdb" version="1">
> <model name="Source" type="PHYSICAL" visible="true">
> <source name="Source" translator-name="hbase" connection-jndi-name="localHBase"/>
> <metadata type="NATIVE"/>
> </model>
> </vdb>
> {code}
> Exception:
> 09:08:06,722 DEBUG [org.teiid.CONNECTOR] (teiid-async-threads - 2) JDBCMetadataProcessor - Importing tables
> 09:08:06,747 DEBUG [org.teiid.CONNECTOR] (teiid-async-threads - 2) JDBCMetadataProcessor - Importing columns
> 09:08:06,748 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS015865: Replaced deployment "test-vdb.xml" with deployment "test-vdb.xml"
> 09:08:06,782 DEBUG [org.teiid.CONNECTOR] (teiid-async-threads - 2) JDBCMetadataProcessor - Importing primary keys
> 09:08:06,905 DEBUG [org.teiid.CONNECTOR] (teiid-async-threads - 2) JDBCMetadataProcessor - Importing index info
> 09:08:06,906 WARN [org.teiid.RUNTIME] (teiid-async-threads - 2) TEIID50036 VDB hbase_test_vdb.1 model "Source" metadata failed to load. Reason:TEIID11010 java.sql.SQLException: ERROR 1101 (XCL01): ResultSet is closed.
> Phoenix driver seems does not support unique indexes (https://github.com/apache/phoenix/blob/master/phoenix-core/src/main/java/...) and returns every time the same ResultSet. After first table, Teiid closes it and next loop fails (https://github.com/teiid/teiid/blob/790e0da722de6f49685ce761302e54772843b...).
> The empty ResultSet is being used across all the PhoenixDatabaseMetaData class:
> getProcedures(...), getIndexes(...), getImportedKeys(...), getFunctions(...), ...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (TEIID-3678) Unable to import native metada from HBase
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3678?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3678:
---------------------------------------
Juraj logged https://issues.apache.org/jira/browse/PHOENIX-2232 to track the issue from the Phoenix side.
> Unable to import native metada from HBase
> -----------------------------------------
>
> Key: TEIID-3678
> URL: https://issues.jboss.org/browse/TEIID-3678
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.10, 8.7.1.6_2
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
> Fix For: 8.12
>
>
> Native metadata cloud not be imported if default values of import properties are used:
> {code:xml}
> <vdb name="hbase_test_vdb" version="1">
> <model name="Source" type="PHYSICAL" visible="true">
> <source name="Source" translator-name="hbase" connection-jndi-name="localHBase"/>
> <metadata type="NATIVE"/>
> </model>
> </vdb>
> {code}
> Exception:
> 09:08:06,722 DEBUG [org.teiid.CONNECTOR] (teiid-async-threads - 2) JDBCMetadataProcessor - Importing tables
> 09:08:06,747 DEBUG [org.teiid.CONNECTOR] (teiid-async-threads - 2) JDBCMetadataProcessor - Importing columns
> 09:08:06,748 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS015865: Replaced deployment "test-vdb.xml" with deployment "test-vdb.xml"
> 09:08:06,782 DEBUG [org.teiid.CONNECTOR] (teiid-async-threads - 2) JDBCMetadataProcessor - Importing primary keys
> 09:08:06,905 DEBUG [org.teiid.CONNECTOR] (teiid-async-threads - 2) JDBCMetadataProcessor - Importing index info
> 09:08:06,906 WARN [org.teiid.RUNTIME] (teiid-async-threads - 2) TEIID50036 VDB hbase_test_vdb.1 model "Source" metadata failed to load. Reason:TEIID11010 java.sql.SQLException: ERROR 1101 (XCL01): ResultSet is closed.
> Phoenix driver seems does not support unique indexes (https://github.com/apache/phoenix/blob/master/phoenix-core/src/main/java/...) and returns every time the same ResultSet. After first table, Teiid closes it and next loop fails (https://github.com/teiid/teiid/blob/790e0da722de6f49685ce761302e54772843b...).
> The empty ResultSet is being used across all the PhoenixDatabaseMetaData class:
> getProcedures(...), getIndexes(...), getImportedKeys(...), getFunctions(...), ...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (TEIID-3589) MongoDB metadata import fails with NPE
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3589?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3589:
-------------------------------------
I have not seen the concept of system tables in the MongoDB, you need to provide a example document what this translator is reading. BTW, this is separate error then original NPE, you probably should open a new JIRA. If you want fixes on the MongoDB translator, we MUST upgrade to the latest version, otherwise, I will just push this to later versions of Teiid where appropriate.
> MongoDB metadata import fails with NPE
> --------------------------------------
>
> Key: TEIID-3589
> URL: https://issues.jboss.org/browse/TEIID-3589
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.7.1.6_2
> Reporter: Van Halbert
> Assignee: Ramesh Reddy
> Labels: Beta1, ER5
> Fix For: 8.7.1.6_2, 8.12
>
>
> Deploying the following dynamic vdb fails with a NullPointerException when Teiid Connection importer is used:
> {code}
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <vdb name="mongo" version="1">
> <description>Importer VDB</description>
> <property name="UseConnectorMetadata" value="true" />
> <property name="deployment-name" value="mongo-vdb.xml" />
> <model name="importVDBSrcModel">
> <source name="importVDBSrcModel" translator-name="mongodb" connection-jndi-name="java:/mongoDS" />
> </model>
> </vdb>
> {code}
> The resource adapter is defined as:
> {code}
> <resource-adapter id="mongoDS">
> <module slot="main" id="org.jboss.teiid.resource-adapter.mongodb"/>
> <transaction-support>NoTransaction</transaction-support>
> <connection-definitions>
> <connection-definition class-name="org.teiid.resource.adapter.mongodb.MongoDBManagedConnectionFactory" jndi-name="java:/mongoDS" enabled="true" use-java-context="true" pool-name="mongoDS">
> <config-property name="Database">
> bqt
> </config-property>
> <config-property name="RemoteServerList">
> vmgdb01.mw.lab.eng.bos.redhat.com:27017
> </config-property>
> <config-property name="Username">
> dv
> </config-property>
> <config-property name="Password">
> dv
> </config-property>
> </connection-definition>
> </connection-definitions>
> </resource-adapter>
> {code}
> Server log:
> {code}
> 16:46:49,793 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) JBAS015876: Starting deployment of "mongo-vdb.xml" (runtime-name: "mongo-vdb.xml")
> 16:46:49,809 DEBUG [org.teiid.RUNTIME] (MSC service thread 1-5) VDB mongo-vdb.xml has been parsed.
> 16:46:49,835 INFO [org.teiid.RUNTIME] (MSC service thread 1-1) TEIID50029 VDB mongo.1 model "importVDBSrcModel" metadata is currently being loaded. Start Time: 7/23/15 4:46 PM
> 16:46:49,869 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS015859: Deployed "mongo-vdb.xml" (runtime-name : "mongo-vdb.xml")
> 16:46:50,626 WARN [org.teiid.RUNTIME] (teiid-async-threads - 3) TEIID50036 VDB mongo.1 model "importVDBSrcModel" metadata failed to load. Reason:java.lang.NullPointerException: java.lang.NullPointerException
> at org.teiid.translator.mongodb.MongoDBMetadataProcessor.addTable(MongoDBMetadataProcessor.java:92)
> at org.teiid.translator.mongodb.MongoDBMetadataProcessor.process(MongoDBMetadataProcessor.java:57)
> at org.teiid.translator.mongodb.MongoDBMetadataProcessor.process(MongoDBMetadataProcessor.java:38)
> at org.teiid.translator.ExecutionFactory.getMetadata(ExecutionFactory.java:935) [teiid-api-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.query.metadata.NativeMetadataRepository.loadMetadata(NativeMetadataRepository.java:73) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.query.metadata.ChainingMetadataRepository.loadMetadata(ChainingMetadataRepository.java:55) [teiid-engine-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.jboss.VDBService$6.run(VDBService.java:395) [teiid-jboss-integration-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at org.teiid.jboss.VDBService$7.run(VDBService.java:442) [teiid-jboss-integration-8.7.1.6_2-redhat-3.jar:8.7.1.6_2-redhat-3]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_79]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_79]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_79]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (TEIID-3681) Subquery field added in wrong place in generated JDBC SQL
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3681?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3681:
---------------------------------------
This is a regression with the partial projection pushing from TEIID-3227
> Subquery field added in wrong place in generated JDBC SQL
> ---------------------------------------------------------
>
> Key: TEIID-3681
> URL: https://issues.jboss.org/browse/TEIID-3681
> Project: Teiid
> Issue Type: Bug
> Reporter: Mark Tawk
> Assignee: Steven Hawkins
>
> I'm using Teiid 8.11.3 and h2 translator:
> I have a query that contains a subquery field in the select statement and a join over another subquery. In the JDBC query executed, i found that the subquery field was added into the subquery join which is giving an error in execution.
> Here is my query:
> SELECT
> "Profile_fqS_030915"."CID" as "Profile_fqS_030915_CID"
> ,
> (
> SELECT
> MAX("Trx_fil_030915_sub"."TransactionDate") as "Trx_fil_030915_TransactionDa"
> FROM
> "implify_data_BanksModel"."implify_data_Banks"."Trx_fil_030915"
> "Trx_fil_030915_sub"
> WHERE
> ("Profile_fqS_030915"."CID" = "Trx_fil_030915_sub"."CID") ) as "SubQuery Trx" ,
> TIMESTAMPDIFF(SQL_TSI_DAY, "Trx"."TransactionDate", PARSETIMESTAMP( '2015-04-02 00:00:00.000', 'yyyy-MM-dd HH:mm:ss.SSS' )) as "CalculatedField2"
> ,
> "Trxmo3UMEoebyXTVyguosX_Sub"."Trxmo3U_CalculatedField12" as
> "Trxmo3U_CalculatedField1"
> ,
> "Trxmo3UMEoebyXTVyguosX_Sub"."Trxmo3U_CalculatedField3" as
> "Trxmo3U_CalculatedField"
> ,
> "Trxmo3UMEoebyXTVyguosX_Sub"."Trxmo3U_CalculatedField11" as
> "Trxmo3U_CalculatedField11"
> ,
> "Trxmo3UMEoebyXTVyguosX_Sub"."Trxmo3U_CalculatedField2" as
> "Trxmo3U_CalculatedField2"
> ,
> "Trxmo3UMEoebyXTVyguosX_Sub"."Trxmo3U_CalculatedField1" as
> "Trxmo3U_CalculatedField12"
> ,
> "Trxmo3UMEoebyXTVyguosX_Sub"."Trxmo3U_CalculatedField" as
> "Trxmo3U_CalculatedField3"
> FROM
> "implify_data_BanksModel"."implify_data_Banks"."Profile_fqS_030915"
> "Profile_fqS_030915"
> LEFT JOIN
> "implify_data_BanksModel"."implify_data_Banks"."Trx_fil_030915" "Trx"
> ON
> "Profile_fqS_030915"."CID" = "Trx"."CID"
> LEFT JOIN
> (
> SELECT
> "Trxmo3U_sub"."Trx_fil_030915_CID" as "Trxmo3U_Trx_fil_030915_CID"
> ,
> MIN("Trxmo3U_sub"."CalculatedField1") as "Trxmo3U_CalculatedField1"
> ,
> MIN("Trxmo3U_sub"."CalculatedField") as "Trxmo3U_CalculatedField"
> ,
> MAX("Trxmo3U_sub"."CalculatedField") as "Trxmo3U_CalculatedField2"
> ,
> MAX("Trxmo3U_sub"."CalculatedField1") as "Trxmo3U_CalculatedField11"
> ,
> AVG(1.0 * "Trxmo3U_sub"."CalculatedField") as "Trxmo3U_CalculatedField3"
> ,
> AVG(1.0 * "Trxmo3U_sub"."CalculatedField1") as "Trxmo3U_CalculatedField12"
> FROM
> "Domain1BusinessModel"."Trxmo3U" "Trxmo3U_sub"
> WHERE
> ( ( ("Trxmo3U_sub"."Trx_fil_030915_Channel" IN ('ATM'
> ,
> 'Branch'
> ,
> 'P.O.S.') ) ) )
> GROUP BY
> "Trxmo3U_sub"."Trx_fil_030915_CID") "Trxmo3UMEoebyXTVyguosX_Sub" ON
> "Profile_fqS_030915"."CID" =
> "Trxmo3UMEoebyXTVyguosX_Sub"."Trxmo3U_Trx_fil_030915_CID" LIMIT 0, 10
> Here is the executed JDBC query:
> SELECT
> g_0."CID" AS c_0,
> (
> SELECT
> MAX(g_4."TransactionDate")
> FROM
> "implify_data_Banks"."Trx_fil_030915" AS g_4
> WHERE
> g_4."CID" = g_0."CID") AS c_1 ,
> g_1."TransactionDate" AS c_2,
> v_0.c_2 AS c_3,
> v_0.c_3 AS c_4,
> v_0.c_4 AS c_5,
> v_0.c_5 AS c_6,
> v_0.c_6 AS c_7,
> v_0.c_7 AS c_8
> FROM
> ("implify_data_Banks"."Profile_fqS_030915" AS g_0
> LEFT OUTER JOIN
> "implify_data_Banks"."Trx_fil_030915" AS g_1
> ON
> g_0."CID" = g_1."CID")
> LEFT OUTER JOIN
> (
> SELECT
> g_2."Trx_fil_030915_CID" AS c_0
> ,
> *_(
> SELECT
> MAX(g_3."TransactionDate")
> FROM
> "implify_data_Banks"."Trx_fil_030915" AS g_3
> WHERE
> g_3."CID" = g_0."CID") AS c_1_* ,
> AVG((1.0 * cast(g_2."CalculatedField1" AS decimal))) AS c_2 ,
> AVG((1.0 * g_2."CalculatedField")) AS c_3 ,
> MAX(g_2."CalculatedField1") AS c_4 ,
> MAX(g_2."CalculatedField") AS c_5 ,
> MIN(g_2."CalculatedField1") AS c_6 ,
> MIN(g_2."CalculatedField") AS c_7
> FROM
> "implify_data_Banks"."Trxmo3U" AS g_2
> WHERE
> g_2."Trx_fil_030915_Channel" IN ('ATM', 'Branch', 'P.O.S.')
> GROUP BY
> g_2."Trx_fil_030915_CID") AS v_0 ON g_0."CID" = v_0.c_0 LIMIT 10
> Error:
> Please try again! TEIID30504 implify_data_BanksModelVDB: 42122 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: []
> Note that if i remove TIMESTAMPDIFF from the main query, the query executes without a problem and the subquery field is no longer added in the join subquery
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (TEIID-3678) Unable to import native metada from HBase
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3678?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-3678:
----------------------------------
Component/s: JDBC Connector
Fix Version/s: 8.12
Affects Version/s: 8.10
8.7.1.6_2
Since we do want primary keys, the importer needs to have importKeys turned on, which is the default. But we'll need to exclude looking at the index information - which is used to determine unique constraints.
> Unable to import native metada from HBase
> -----------------------------------------
>
> Key: TEIID-3678
> URL: https://issues.jboss.org/browse/TEIID-3678
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.10, 8.7.1.6_2
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
> Fix For: 8.12
>
>
> Native metadata cloud not be imported if default values of import properties are used:
> {code:xml}
> <vdb name="hbase_test_vdb" version="1">
> <model name="Source" type="PHYSICAL" visible="true">
> <source name="Source" translator-name="hbase" connection-jndi-name="localHBase"/>
> <metadata type="NATIVE"/>
> </model>
> </vdb>
> {code}
> Exception:
> 09:08:06,722 DEBUG [org.teiid.CONNECTOR] (teiid-async-threads - 2) JDBCMetadataProcessor - Importing tables
> 09:08:06,747 DEBUG [org.teiid.CONNECTOR] (teiid-async-threads - 2) JDBCMetadataProcessor - Importing columns
> 09:08:06,748 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS015865: Replaced deployment "test-vdb.xml" with deployment "test-vdb.xml"
> 09:08:06,782 DEBUG [org.teiid.CONNECTOR] (teiid-async-threads - 2) JDBCMetadataProcessor - Importing primary keys
> 09:08:06,905 DEBUG [org.teiid.CONNECTOR] (teiid-async-threads - 2) JDBCMetadataProcessor - Importing index info
> 09:08:06,906 WARN [org.teiid.RUNTIME] (teiid-async-threads - 2) TEIID50036 VDB hbase_test_vdb.1 model "Source" metadata failed to load. Reason:TEIID11010 java.sql.SQLException: ERROR 1101 (XCL01): ResultSet is closed.
> Phoenix driver seems does not support unique indexes (https://github.com/apache/phoenix/blob/master/phoenix-core/src/main/java/...) and returns every time the same ResultSet. After first table, Teiid closes it and next loop fails (https://github.com/teiid/teiid/blob/790e0da722de6f49685ce761302e54772843b...).
> The empty ResultSet is being used across all the PhoenixDatabaseMetaData class:
> getProcedures(...), getIndexes(...), getImportedKeys(...), getFunctions(...), ...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months