[JBoss JIRA] (TEIID-4427) Migration to Teiid 9.0.0 - Materialized views error: Expected integer, but was bigdecimal
by Mark Tawk (JIRA)
[ https://issues.jboss.org/browse/TEIID-4427?page=com.atlassian.jira.plugin... ]
Mark Tawk commented on TEIID-4427:
----------------------------------
When using MAX aggregate function, the source code I sent in the previous message return *Long*
Only when using COUNT aggregate function, it is returning *Integer*
> Migration to Teiid 9.0.0 - Materialized views error: Expected integer, but was bigdecimal
> -----------------------------------------------------------------------------------------
>
> Key: TEIID-4427
> URL: https://issues.jboss.org/browse/TEIID-4427
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 9.0
> Reporter: Mark Tawk
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 9.1, 9.0.5
>
>
> After migrating to Teiid 9.0.0, we are facing issues with existing views materialized on Oracle server.
> when fetching an Oracle materialized view that contains a column using date function like : "Month" or "Year" or "TIMESTAMPDIFF", we are getting the error : Expected integer, but was bigdecimal.
> If we go back to Teiid 8.11.3, the same materialized views fetch without any problem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (TEIID-4427) Migration to Teiid 9.0.0 - Materialized views error: Expected integer, but was bigdecimal
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4427?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4427:
---------------------------------------
> i'm counting on ResultSetMetaDataImpl to create the view and stage tables columns data types; in the case of Aggregate function COUNT, the meta is returning Integer.
That is correct that count returns an integer. From that you are creating the DDL for a mysql table? Are you mapping that to an unsigned int in mysql?
I'm still fuzzy on just exactly how the Teiid metadata for the materialization target is being created. It seems from these comments that it must be happening via the translator import - but that hasn't changed in any significant way in between the releases in question.
> Migration to Teiid 9.0.0 - Materialized views error: Expected integer, but was bigdecimal
> -----------------------------------------------------------------------------------------
>
> Key: TEIID-4427
> URL: https://issues.jboss.org/browse/TEIID-4427
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 9.0
> Reporter: Mark Tawk
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 9.1, 9.0.5
>
>
> After migrating to Teiid 9.0.0, we are facing issues with existing views materialized on Oracle server.
> when fetching an Oracle materialized view that contains a column using date function like : "Month" or "Year" or "TIMESTAMPDIFF", we are getting the error : Expected integer, but was bigdecimal.
> If we go back to Teiid 8.11.3, the same materialized views fetch without any problem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (TEIID-4427) Migration to Teiid 9.0.0 - Materialized views error: Expected integer, but was bigdecimal
by Mark Tawk (JIRA)
[ https://issues.jboss.org/browse/TEIID-4427?page=com.atlassian.jira.plugin... ]
Mark Tawk edited comment on TEIID-4427 at 9/14/16 9:42 AM:
-----------------------------------------------------------
i'm counting on ResultSetMetaDataImpl to create the view and stage tables columns data types; in the case of Aggregate function COUNT, the meta is returning Integer.
Here is the code used in this concern:
....
StatementImpl stmt = (StatementImpl) conn.createStatement();
ResultSetMetaDataImpl meta = (ResultSetMetaDataImpl) stmt.getResultSet().getMetaData();
for (int j = 1; j <= meta.getColumnCount(); j++) {
int colType = meta.getColumnType(j);
String className = JDBCSQLTypeInfo.getJavaClassName(colType);
......
}
was (Author: mtawk):
i'm counting on ResultSetMetaDataImpl to create the view and stage tables columns data types; in the case of Aggregate function COUNT, the meta is returning Integer.
Here is the code used in this concern:
....
IntegerStatementImpl stmt = (StatementImpl) conn.createStatement();
ResultSetMetaDataImpl meta = (ResultSetMetaDataImpl) stmt.getResultSet().getMetaData();
for (int j = 1; j <= meta.getColumnCount(); j++) {
int colType = meta.getColumnType(j);
String className = JDBCSQLTypeInfo.getJavaClassName(colType);
......
}
> Migration to Teiid 9.0.0 - Materialized views error: Expected integer, but was bigdecimal
> -----------------------------------------------------------------------------------------
>
> Key: TEIID-4427
> URL: https://issues.jboss.org/browse/TEIID-4427
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 9.0
> Reporter: Mark Tawk
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 9.1, 9.0.5
>
>
> After migrating to Teiid 9.0.0, we are facing issues with existing views materialized on Oracle server.
> when fetching an Oracle materialized view that contains a column using date function like : "Month" or "Year" or "TIMESTAMPDIFF", we are getting the error : Expected integer, but was bigdecimal.
> If we go back to Teiid 8.11.3, the same materialized views fetch without any problem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (TEIID-4427) Migration to Teiid 9.0.0 - Materialized views error: Expected integer, but was bigdecimal
by Mark Tawk (JIRA)
[ https://issues.jboss.org/browse/TEIID-4427?page=com.atlassian.jira.plugin... ]
Mark Tawk edited comment on TEIID-4427 at 9/14/16 9:41 AM:
-----------------------------------------------------------
i'm counting on ResultSetMetaDataImpl to create the view and stage tables columns data types; in the case of Aggregate function COUNT, the meta is returning Integer.
Here is the code used in this concern:
....
IntegerStatementImpl stmt = (StatementImpl) conn.createStatement();
ResultSetMetaDataImpl meta = (ResultSetMetaDataImpl) stmt.getResultSet().getMetaData();
for (int j = 1; j <= meta.getColumnCount(); j++) {
int colType = meta.getColumnType(j);
String className = JDBCSQLTypeInfo.getJavaClassName(colType);
......
}
was (Author: mtawk):
i'm counting on ResultSetMetaDataImpl to create the view and stage tables columns data types; in the case of Aggregate function COUNT, the meta is returning Integer.
Here is the code used in this concern:
....
IntegerStatementImpl stmt = (StatementImpl) conn.createStatement();
ResultSetMetaDataImpl meta = (ResultSetMetaDataImpl) stmt.getResultSet().getMetaData();
for (int j = 1; j <= meta.getColumnCount(); j++) {
int colType = meta.getColumnType(j);
String className = JDBCSQLTypeInfo.getJavaClassName(typeCode);
......
}
> Migration to Teiid 9.0.0 - Materialized views error: Expected integer, but was bigdecimal
> -----------------------------------------------------------------------------------------
>
> Key: TEIID-4427
> URL: https://issues.jboss.org/browse/TEIID-4427
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 9.0
> Reporter: Mark Tawk
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 9.1, 9.0.5
>
>
> After migrating to Teiid 9.0.0, we are facing issues with existing views materialized on Oracle server.
> when fetching an Oracle materialized view that contains a column using date function like : "Month" or "Year" or "TIMESTAMPDIFF", we are getting the error : Expected integer, but was bigdecimal.
> If we go back to Teiid 8.11.3, the same materialized views fetch without any problem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (TEIID-4427) Migration to Teiid 9.0.0 - Materialized views error: Expected integer, but was bigdecimal
by Mark Tawk (JIRA)
[ https://issues.jboss.org/browse/TEIID-4427?page=com.atlassian.jira.plugin... ]
Mark Tawk commented on TEIID-4427:
----------------------------------
i'm counting on ResultSetMetaDataImpl to create the view and stage tables columns data types; in the case of Aggregate function COUNT, the meta is returning Integer.
Here is the code used in this concern:
....
IntegerStatementImpl stmt = (StatementImpl) conn.createStatement();
ResultSetMetaDataImpl meta = (ResultSetMetaDataImpl) stmt.getResultSet().getMetaData();
for (int j = 1; j <= meta.getColumnCount(); j++) {
int colType = meta.getColumnType(j);
String className = JDBCSQLTypeInfo.getJavaClassName(typeCode);
......
}
> Migration to Teiid 9.0.0 - Materialized views error: Expected integer, but was bigdecimal
> -----------------------------------------------------------------------------------------
>
> Key: TEIID-4427
> URL: https://issues.jboss.org/browse/TEIID-4427
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 9.0
> Reporter: Mark Tawk
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 9.1, 9.0.5
>
>
> After migrating to Teiid 9.0.0, we are facing issues with existing views materialized on Oracle server.
> when fetching an Oracle materialized view that contains a column using date function like : "Month" or "Year" or "TIMESTAMPDIFF", we are getting the error : Expected integer, but was bigdecimal.
> If we go back to Teiid 8.11.3, the same materialized views fetch without any problem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (TEIID-4427) Migration to Teiid 9.0.0 - Materialized views error: Expected integer, but was bigdecimal
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4427?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4427:
---------------------------------------
Here again it will matter how the mysql source table metadata is defined in Teiid. By default the translator will widen unsigned types, so an unsigned int in mysql will be represented by a long in Teiid.
> Migration to Teiid 9.0.0 - Materialized views error: Expected integer, but was bigdecimal
> -----------------------------------------------------------------------------------------
>
> Key: TEIID-4427
> URL: https://issues.jboss.org/browse/TEIID-4427
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 9.0
> Reporter: Mark Tawk
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 9.1, 9.0.5
>
>
> After migrating to Teiid 9.0.0, we are facing issues with existing views materialized on Oracle server.
> when fetching an Oracle materialized view that contains a column using date function like : "Month" or "Year" or "TIMESTAMPDIFF", we are getting the error : Expected integer, but was bigdecimal.
> If we go back to Teiid 8.11.3, the same materialized views fetch without any problem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (TEIID-4427) Migration to Teiid 9.0.0 - Materialized views error: Expected integer, but was bigdecimal
by Mark Tawk (JIRA)
[ https://issues.jboss.org/browse/TEIID-4427?page=com.atlassian.jira.plugin... ]
Mark Tawk commented on TEIID-4427:
----------------------------------
I'm getting a similar issue on Mysql when using COUNT aggregate function into a materialized view.
The view materializes successfully but whenever i fetch it, I'm getting the error: Expected integer, but was long.
> Migration to Teiid 9.0.0 - Materialized views error: Expected integer, but was bigdecimal
> -----------------------------------------------------------------------------------------
>
> Key: TEIID-4427
> URL: https://issues.jboss.org/browse/TEIID-4427
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 9.0
> Reporter: Mark Tawk
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 9.1, 9.0.5
>
>
> After migrating to Teiid 9.0.0, we are facing issues with existing views materialized on Oracle server.
> when fetching an Oracle materialized view that contains a column using date function like : "Month" or "Year" or "TIMESTAMPDIFF", we are getting the error : Expected integer, but was bigdecimal.
> If we go back to Teiid 8.11.3, the same materialized views fetch without any problem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (TEIID-4437) Convert Teiid build to use "feature-pack"
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-4437?page=com.atlassian.jira.plugin... ]
Kylin Soong commented on TEIID-4437:
------------------------------------
Some translator depend on engine, eg, translator-accumulo define a EvaluatorIterator which use engine api like
{code}
import org.teiid.query.sql.lang.Criteria;
import org.teiid.query.sql.symbol.ElementSymbol;
import org.teiid.query.sql.symbol.GroupSymbol;
{code}
and engine jar in wildfly integration's module {name='org.jboss.teiid', slot='main'}. I think re-design modules folder architecture is not a good choice, I move connector build after wildfly-integration, make sure new change can build all dist successful as previous, then consider enhance.
> Convert Teiid build to use "feature-pack"
> -----------------------------------------
>
> Key: TEIID-4437
> URL: https://issues.jboss.org/browse/TEIID-4437
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits
> Reporter: Ramesh Reddy
> Assignee: Kylin Soong
> Fix For: 9.2
>
>
> Change the current build process to build "feature-packs" for project, and then based on feature pack, build
> - WildFly Server distribution
> -WildFly Server Overlay distribution
> Teiid currently have distributions, but not based on feature-packs, they need to be. Other distributions like AdminShell do not fall into this category. Only distributions that has WF involvement need a feature -pack (this is important to remember).
> Currently Teiid uses "kit" directory in many different projects along with "wildfly-dist.xml" to populate "modules" directory. A feature-pack does EXACTLY same thing, but more with checks and balances. A feature pack, makes sure all the dependencies are met based on module.xml and module.xml defines the maven artifact rather than JAR file. i.e. it defines a metadata file, from which it can be build the zip file that "wildfly-dist.xml" assembly is currently doing. It also can has capabilities to "configure" the WF subsystem. That is manually done or done through CLI currently, using this part will be new.
> Implementation Rules
> 1) Every where we have "kit" directory, that module REQUIRES a "feature-pack" module. That means, every translator and resource-adapter gets it's own, and Teiid engine modules separately gets its own module. The reason to keep/create multiple modules is STRICTLY to keep the "modules" directory in feature-pack aligned ONE TO ONE with project that feature-pack represents. Otherwise, as developer we will NOT know which project is bringing in certain dependency, if all the modules are in single place. So, this is more about management of dependencies in a sane way. (Teiid did have all the modules in once place before in 7.x/8.x time, it is a nightmare to handle growing dependencies with our translators)
> 2) NONE of the work we have is useless/or need to be redone, most everything we have PERFECTLY maps to this effort, except for for configuration part.
> 3) For translator and resource adapter pair, I recommend that we pull them into single sub folder, and create a single feature pack for it. For example:
> we have
> {code}
> connectors/translator-mongodb
> connectors/connector-mongodb
> {code}
> I would like see we design as
> {code}
> connectors
> /mongdb
> /translator-mongodb
> /connector-mongodb
> /feature-pack-mongodb
> {code}
> No need to create "dist" packages for any resource-adapters or translators. As I mentioned in the beginning of the issue, there are two distributions, they are built using these various feature-packs.
> 4) I would like to see a clean move of "kit/wildfly/modules" to "feature-packs" using "git", NOT CUT n PASTE where we loose the GIT history. This will preserve the confidence that what we have currently is EXACTLY same as in future with feature-packs.
> 5) When designing the "feature-pack" projects, they ABSOLUTELY MUST NOT define any dependencies in their pom.xml other than Teiid project(s) they represent and any other feature-pack they refer to. (Kylin this is what cause most concern from your design for me)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (TEIID-4325) ASSERTION FAILED: expected reference to be not null
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4325?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-4325:
----------------------------------
Fix Version/s: 8.13.7
> ASSERTION FAILED: expected reference to be not null
> ---------------------------------------------------
>
> Key: TEIID-4325
> URL: https://issues.jboss.org/browse/TEIID-4325
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.12
> Reporter: Mark Tawk
> Assignee: Steven Hawkins
> Fix For: 9.1, 9.0.2, 8.13.7, 8.12.6.6_3
>
> Attachments: show_plan_debug.txt
>
>
> I'm using teiid 9.0.0 over h2 :
>
> I'm getting ASSERTION_FAILED over the following query and can not find what is causing this exception:
>
> select "Sheet1"."AvgAmoutRange" as "Sheet1_EBt_211215_AvgAmoutRa1",COUNT( distinct IFNULL("CEGlobalView"."Customer_CustomerID",-2147483648)) as "CEGlobalView_Customer_Custom2","CEGlobalView"."Customer_GenderID" as "CEGlobalView_Customer_Gender1","Gender"."Gender" as "Gender_Gender","Sheet1"."Sheet1_EBt_211215ID" as "Sheet1_EBt_211215_Sheet1_EBt11" from "CEBanksBusinessModel"."CEGlobalView" "CEGlobalView" LEFT JOIN "h2dbimplify_data_cebankModel_ST"."implify_data_cebank"."Sheet1_EBt_211215" "Sheet1" ON ( ("CEGlobalView"."StreamCardsvt3r_StreamCards_1" BETWEEN "Sheet1"."Min" and "Sheet1"."Max") )
> LEFT JOIN "h2dbimplify_data_cebankModel_fR"."implify_data_cebank"."Gender" "Gender" ON "CEGlobalView"."Customer_GenderID" = "Gender"."GenderID"
> LEFT JOIN "h2dbimplify_data_cebankModel_fR"."implify_data_cebank"."CustomerTag" "CustomerTag" ON "CEGlobalView"."Customer_CustomerID" = "CustomerTag"."Customer_CustomerID" AND ( ( ("CustomerTag"."EndDateTime" > CURDATE()) OR ( ("CustomerTag"."EndDateTime" IS null ) ) ) )
> LEFT JOIN "h2dbimplify_data_cebankModel_fR"."implify_data_cebank"."TagValue" "TagValue" ON "CustomerTag"."TagValue_TagValueID" = "TagValue"."TagValueID"
> LEFT JOIN "h2dbimplify_data_cebankModel_fR"."implify_data_cebank"."TagName" "TagName" ON "TagValue"."TagName_TagNameID" = "TagName"."TagNameID" AND ( ( ("TagName"."TagType_TagTypeID" IN (1.0) ) ) AND ( ("TagName"."TagScope_TagScopeID" IN (1.0) ) ) )
> where ( ( ( ("TagName"."TagName" IN ('Behavior') ) ) ) AND ( ("Sheet1"."AvgAmoutRange" IS NOT null ) ) AND ( ("CEGlobalView"."Customer_GenderID" IS NOT null ) ) AND ( ("Gender"."Gender" IS NOT null ) ) ) group by "Sheet1"."AvgAmoutRange","CEGlobalView"."Customer_GenderID","Gender"."Gender","Sheet1"."Sheet1_EBt_211215ID" order by "Sheet1"."Sheet1_EBt_211215ID" ASC,"Sheet1"."AvgAmoutRange" ASC,"Gender"."Gender" DESC,"CEGlobalView"."Customer_GenderID" DESC
>
> The exception stack:
>
> ERROR TEIID_DQP_LOGGER:90 (http-bio-8080-exec-14) - - [TEIID30019 Unexpected exception for request rBDBCRYcUyyM.0]
> java.lang.AssertionError: ASSERTION FAILED: expected reference to be not null
> at org.teiid.core.util.Assertion.failed(Assertion.java:73)
> at org.teiid.core.util.Assertion.isNotNull(Assertion.java:100)
> at org.teiid.core.util.Assertion.isNotNull(Assertion.java:92)
> at org.teiid.query.processor.relational.RelationalNode.getProjectionIndexes(RelationalNode.java:367)
> at org.teiid.query.processor.relational.JoinNode.initialize(JoinNode.java:133)
> at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:96)
> at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:102)
> at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:102)
> at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:102)
> at org.teiid.query.processor.relational.RelationalPlan.initialize(RelationalPlan.java:91)
> at org.teiid.query.processor.QueryProcessor.init(QueryProcessor.java:226)
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:138)
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146)
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:472)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:348)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:274)
> at org.teiid.dqp.internal.process.DQPCore.executeRequest(DQPCore.java:313)
> at org.teiid.dqp.internal.process.DQPCore.executeRequest(DQPCore.java:245)
> at sun.reflect.GeneratedMethodAccessor423.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.teiid.transport.LocalServerConnection$1$1.call(LocalServerConnection.java:177)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:260)
> at org.teiid.transport.LocalServerConnection$1.invoke(LocalServerConnection.java:175)
> at com.sun.proxy.$Proxy34.executeRequest(Unknown Source)
> at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:673)
> at org.teiid.jdbc.StatementImpl.executeSql(StatementImpl.java:539)
> at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:1060)
> at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:323)
> you find attached the show plan debug
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (TEIID-4445) Optimizer NPE In RuleChooseDependent.findCandidate
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4445?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4445.
-----------------------------------
Resolution: Duplicate Issue
Duplicate of TEIID-4325 - same cause but a different planning exception. I'll add TEIID-4325 to the 8.13.7 release.
> Optimizer NPE In RuleChooseDependent.findCandidate
> --------------------------------------------------
>
> Key: TEIID-4445
> URL: https://issues.jboss.org/browse/TEIID-4445
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.13.2
> Reporter: Ehud Reches
> Assignee: Steven Hawkins
> Attachments: app1-vdb.xml, query.sql, schema.sql
>
>
> The attached query against a VDB with a single federated Oracle database causes an NPE in org.teiid.query.optimizer.relational.rules.RuleChooseDependent.findCandidate. Was reproduced independently at our customer site and by us:
> org.teiid.core.TeiidException SELECT count(*) from SF_OPPORTUNITY OPP INNER JOIN DIM_DATE_EXTN ON MODIFYTIMEZONE(OPP.CREATEDDATE,'GMT','PST') = DIM_DATE_EXTN.CLNDR_DT INNER JOIN SF_USER OWNER_USR ON OPP.OWNERID = OWNER_USR.ID INNER JOIN SF_USER CREATED_USR ON OPP.CREATEDBYID = CREATED_USR.ID LEFT OUTER JOIN FACT_BOOKING FB ON OPP.ID = FB.SALE_ORDER_HDR_ID LEFT OUTER JOIN SF_PRICEBOOK2 PB2 ON OPP.PRICEBOOK2ID = PB2.ID LEFT OUTER JOIN RPTCOMPANYIDS_1 QBO ON CAST(OPP.COMPANY_ID__C as varchar (25)) = CAST(QBO.COMPANY_ID as varchar (25)) LEFT OUTER JOIN SF_OPPORTUNITYLINEITEM OPP_L ON OPP.ID = OPP_L.OPPORTUNITYID LEFT OUTER JOIN SF_OPPORTUNITYLINEITEM OPP_LI ON OPP_LI.ID = FB.SALE_ORDER_LINE_ID LEFT OUTER JOIN SF_PRODUCT2 PR ON OPP_L.PRODUCT2ID = PR.ID LEFT OUTER JOIN SF_PRICEBOOKENTRY PBE ON (PR.ID = PBE.PRODUCT2ID AND PB2.ID = PBE.PRICEBOOK2ID) LEFT OUTER JOIN DTL_PAYCYCLE PC ON CAST(OPP.COMPANY_ID__C as varchar (25)) = CAST(PC.QBOCOMPANYID as varchar (25)) LEFT OUTER JOIN (SELECT * FROM DIM_EMPLOYEE WHERE EMAIL_ADDR IS NOT NULL) C_AGENT ON C_AGENT.CORP_ID = CREATED_USR.FEDERATIONIDENTIFIER LEFT OUTER JOIN DIM_EMPLOYEE_DIVISION C_AGENT_DIVISION ON C_AGENT.DIM_EMPLOYEE_KEY = C_AGENT_DIVISION.DIM_EMPLOYEE_KEY AND MODIFYTIMEZONE(OPP.CREATEDDATE,'GMT','PST') >= NVL(C_AGENT_DIVISION.REC_START_DATE,'01-JAN-13') AND MODIFYTIMEZONE(OPP.CREATEDDATE,'GMT','PST') <= NVL(C_AGENT_DIVISION.REC_END_DATE,'01-JAN-50') LEFT OUTER JOIN DIM_DIVISION_PIVOT_VW C_DIVISION ON C_DIVISION.DIM_DIVISION_KEY = C_AGENT_DIVISION.DIM_DIVISION_KEY LEFT OUTER JOIN DIM_EMPLOYEE_LOGIN C_AGENT_LOGIN ON C_AGENT_LOGIN.DIM_EMPLOYEE_KEY = C_AGENT.DIM_EMPLOYEE_KEY AND MODIFYTIMEZONE(OPP.CREATEDDATE,'GMT','PST') >= NVL(C_AGENT_LOGIN.REC_START_DATE,'01-JAN-13') AND MODIFYTIMEZONE(OPP.CREATEDDATE,'GMT','PST') <= NVL(C_AGENT_LOGIN.REC_END_DATE,'01-JAN-50') LEFT OUTER JOIN DIM_EMPLOYEE C_AGENT_MGR ON C_AGENT_MGR.DIM_EMPLOYEE_KEY = C_AGENT_LOGIN.MANAGER_EMPLOYEE_KEY LEFT OUTER JOIN (SELECT * FROM DIM_EMPLOYEE WHERE EMAIL_ADDR IS NOT NULL) AGENT ON AGENT.CORP_ID = OWNER_USR.FEDERATIONIDENTIFIER LEFT OUTER JOIN DIM_EMPLOYEE_DIVISION AGENT_DIVISION ON AGENT.DIM_EMPLOYEE_KEY = AGENT_DIVISION.DIM_EMPLOYEE_KEY AND MODIFYTIMEZONE(OPP.CREATEDDATE,'GMT','PST') >= NVL(AGENT_DIVISION.REC_START_DATE,'01-JAN-13') AND MODIFYTIMEZONE(OPP.CREATEDDATE,'GMT','PST') <= NVL(AGENT_DIVISION.REC_END_DATE,'01-JAN-50') LEFT OUTER JOIN DIM_DIVISION_PIVOT_VW DIVISION ON DIVISION.DIM_DIVISION_KEY = AGENT_DIVISION.DIM_DIVISION_KEY LEFT OUTER JOIN DIM_EMPLOYEE_LOGIN AGENT_LOGIN ON AGENT_LOGIN.DIM_EMPLOYEE_KEY = AGENT.DIM_EMPLOYEE_KEY AND MODIFYTIMEZONE(OPP.CREATEDDATE,'GMT','PST') >= NVL(AGENT_LOGIN.REC_START_DATE,'01-JAN-13') AND MODIFYTIMEZONE(OPP.CREATEDDATE,'GMT','PST') <= NVL(AGENT_LOGIN.REC_END_DATE,'01-JAN-50') LEFT OUTER JOIN DIM_EMPLOYEE AGENT_MGR ON AGENT_MGR.DIM_EMPLOYEE_KEY = AGENT_LOGIN.MANAGER_EMPLOYEE_KEY LEFT OUTER JOIN SF_CAMPAIGNMEMBER CM ON CM.LEADID = OPP.ID LEFT OUTER JOIN SF_CAMPAIGN C ON C.ID = CM.CAMPAIGNID WHERE ( DIVISION.DIM_SCENARIO_KEY = 2 OR DIVISION.DIM_SCENARIO_KEY IS NULL) AND ( C_DIVISION.DIM_SCENARIO_KEY = 2 OR C_DIVISION.DIM_SCENARIO_KEY IS NULL) AND OPP.ISDELETED = 0 AND (OPP.CLOSEDATE IS NULL OR OPP.CLOSEDATE <= TIMESTAMPADD(SQL_TSI_DAY , 60, now())) AND (C_DIVISION.DIVISION_L6_NAME IN ('APD Sales','Telesales') OR DIVISION.DIVISION_L6_NAME IN ('APD Sales','Telesales')) AND DIM_DATE_EXTN.CLNDR_DT >= '01-JUN-15' AND C_DIVISION.DIVISION_L5_NAME = 'SBFS Sales'
> org.teiid.jdbc.TeiidSQLException: org.teiid.core.TeiidException
> at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:135)
> at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:71)
> at org.teiid.jdbc.StatementImpl.postReceiveResults(StatementImpl.java:706)
> at org.teiid.jdbc.StatementImpl.access$100(StatementImpl.java:64)
> at org.teiid.jdbc.StatementImpl$2.onCompletion(StatementImpl.java:545)
> at org.teiid.client.util.ResultsFuture.done(ResultsFuture.java:135)
> at org.teiid.client.util.ResultsFuture.access$200(ResultsFuture.java:40)
> at org.teiid.client.util.ResultsFuture$1.receiveResults(ResultsFuture.java:79)
> at org.teiid.net.socket.SocketServerInstanceImpl.receivedMessage(SocketServerInstanceImpl.java:268)
> at org.teiid.net.socket.SocketServerInstanceImpl.read(SocketServerInstanceImpl.java:306)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.teiid.net.socket.SocketServerConnectionFactory$ShutdownHandler.invoke(SocketServerConnectionFactory.java:98)
> at com.sun.proxy.$Proxy97.read(Unknown Source)
> at org.teiid.net.socket.SocketServerInstanceImpl$RemoteInvocationHandler$1.get(SocketServerInstanceImpl.java:405)
> at org.teiid.jdbc.StatementImpl.executeSql(StatementImpl.java:554)
> at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:1076)
> at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:323)
> at plat36961.SQLExecuter.exceSQL(SQLExecuter.java:121)
> at plat36961.SQLExecuter.execStatements(SQLExecuter.java:65)
> at plat36961.ComplexQueryTest.runComplexQuery(ComplexQueryTest.java:83)
> at plat36961.ComplexQueryTest.runTest(ComplexQueryTest.java:76)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
> at com.attivio.junit.rules.CleanupHooksRule$1.evaluate(CleanupHooksRule.java:36)
> at com.attivio.junit.rules.DisplayLeftoverThreadsRule$1.evaluate(DisplayLeftoverThreadsRule.java:32)
> at com.attivio.junit.rules.CheckBaseportRule$1.evaluate(CheckBaseportRule.java:26)
> at com.attivio.junit.rules.ResetHttpConnectionManagerRule$1.evaluate(ResetHttpConnectionManagerRule.java:26)
> at com.attivio.junit.rules.KillExternalProcessesRule$1.evaluate(KillExternalProcessesRule.java:50)
> at org.junit.rules.RunRules.evaluate(RunRules.java:18)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at com.attivio.junit.runners.JUnit4EnhancedTimeoutClassRunner.runChild(JUnit4EnhancedTimeoutClassRunner.java:112)
> at com.attivio.junit.runners.JUnit4EnhancedTimeoutClassRunner.runChild(JUnit4EnhancedTimeoutClassRunner.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: org.teiid.core.TeiidException
> at org.teiid.client.ResultsMessage.setException(ResultsMessage.java:196)
> at org.teiid.dqp.internal.process.RequestWorkItem.sendError(RequestWorkItem.java:1084)
> at org.teiid.dqp.internal.process.RequestWorkItem.close(RequestWorkItem.java:576)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:374)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:274)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at org.teiid.query.optimizer.relational.rules.RuleChooseDependent.findCandidate(RuleChooseDependent.java:196)
> at org.teiid.query.optimizer.relational.rules.RuleChooseDependent.execute(RuleChooseDependent.java:100)
> at org.teiid.query.optimizer.relational.RelationalPlanner.executeRules(RelationalPlanner.java:834)
> at org.teiid.query.optimizer.relational.RelationalPlanner.optimize(RelationalPlanner.java:224)
> at org.teiid.query.optimizer.QueryOptimizer.optimizePlan(QueryOptimizer.java:159)
> at org.teiid.dqp.internal.process.Request.generatePlan(Request.java:440)
> at org.teiid.dqp.internal.process.Request.processRequest(Request.java:468)
> at org.teiid.dqp.internal.process.RequestWorkItem.processNew(RequestWorkItem.java:640)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:337)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months