[JBoss JIRA] (TEIID-3802) HANA translator modifies boolean to tinyint in type conversion
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3802?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3802:
------------------------------------------------
Filip Elias <felias(a)redhat.com> changed the Status of [bug 1278409|https://bugzilla.redhat.com/show_bug.cgi?id=1278409] from VERIFIED to CLOSED
> HANA translator modifies boolean to tinyint in type conversion
> --------------------------------------------------------------
>
> Key: TEIID-3802
> URL: https://issues.jboss.org/browse/TEIID-3802
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.1.6_2
> Reporter: Jan Stastny
> Assignee: Steven Hawkins
> Fix For: 8.12.2, 8.13
>
>
> Teiid modifies boolean data type to tinyint before pushing the query down to the HANA instance.
> This brings following issue while having a query similar to this one:
> {code:sql}
> SELECT BQT1.SMallA.BooleanValue,cast(BQT2.SmallB.CharValue as boolean) FROM BQT1.SmallA,BQT2.SmallB WHERE BQT1.SmallA.BooleanValue = cast(BQT2.SmallB.CharValue as boolean)
> {code}
> which Teiid modifies to:
> {code:sql}
> SELECT g_0."BOOLEANVALUE", cast(g_1."CHARVALUE" AS tinyint) FROM "BQT1"."SMALLA" AS g_0, "BQT2"."SMALLB" AS g_1 WHERE g_0."BOOLEANVALUE" = cast(g_1."CHARVALUE" AS tinyint)
> {code}
> But the problem is not present for:
> {code:sql}
> SELECT BQT1.SMallA.BooleanValue FROM BQT1.SmallA WHERE BQT1.SmallA.BooleanValue = cast(BQT1.SmallA.CharValue as boolean)
> {code}
> It seems that the Cartesian product and comparing values from different sources are the cause of the issue. But HANA has internal type BOOLEAN, so there might be no point at modifying the type to TINYINT after all. I also checked, that the pushed query (which causes the issue) with the casting altered to BOOLEAN runs well on HANA. The following query returns expected results when pushed directly to HANA instance:
> {code:sql}
> SELECT g_0."BOOLEANVALUE", cast(g_1."CHARVALUE" AS boolean) FROM "BQT1"."SMALLA" AS g_0, "BQT2"."SMALLB" AS g_1 WHERE g_0."BOOLEANVALUE" = cast(g_1."CHARVALUE" AS boolean)
> {code}
> NOTE: The CharValue columns are modelled as VARCHAR/string in fact. Thus the cast is a valid operation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (TEIID-4054) OData - creation of entity (POST) returns exception (status code 500)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-4054?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-4054:
------------------------------------------------
Filip Elias <felias(a)redhat.com> changed the Status of [bug 1316490|https://bugzilla.redhat.com/show_bug.cgi?id=1316490] from VERIFIED to CLOSED
> OData - creation of entity (POST) returns exception (status code 500)
> ---------------------------------------------------------------------
>
> Key: TEIID-4054
> URL: https://issues.jboss.org/browse/TEIID-4054
> Project: Teiid
> Issue Type: Sub-task
> Components: OData
> Reporter: Juraj Duráni
> Assignee: Ramesh Reddy
> Labels: alpha3
> Fix For: 9.0, 8.12.5
>
>
> Creation of entity returns exception \[1\]. Representation of entity \[2\]. Http request \[3\]. Header \[4\]. Same exception with of JSON format.
> \[1\]
> {code:plain}
> TEIID10076 Invalid conversion from type class java.lang.Object with value 'java.util.GregorianCalendar[time=4000,areFieldsSet=true,areAllFieldsSet=true,
> lenient=true,zone=sun.util.calendar.ZoneInfo[id="GMT",offset=0,dstSavings=0,useDaylight=false,transitions=0,lastRule=null],f
> irstDayOfWeek=2,minimalDaysInFirstWeek=4,ERA=1,YEAR=1970,MONTH=0,WEEK_OF_YEAR=1,
> WEEK_OF_MONTH=1,DAY_OF_MONTH=1,DAY_OF_YEAR=1,DAY_OF_WEEK=5,DAY_OF_WEEK_IN_MONTH=1,
> AM_PM=0,HOUR=0,HOUR_OF_DAY=0,MINUTE=0,SECOND=4,MILLISECOND=0,ZONE_OFFSET=0,DST_OFFSET=0]'
> to type class java.sql.Time
> {code}
> \[2\]
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <entry xmlns="http://www.w3.org/2005/Atom" xmlns:d="http://docs.oasis-open.org/odata/ns/data" xmlns:georss="http://www.georss.org/georss" xmlns:gml="http://www.opengis.net/gml" xmlns:m="http://docs.oasis-open.org/odata/ns/metadata">
> <category scheme="http://docs.oasis-open.org/odata/ns/scheme" />
> <content type="application/xml">
> <m:properties>
> <d:intkey m:type="Int32">4</d:intkey>
> <d:intnum m:type="Int32">4</d:intnum>
> <d:stringkey>4</d:stringkey>
> <d:stringval>value_4</d:stringval>
> <d:booleanval m:type="Boolean">false</d:booleanval>
> <d:decimalval m:type="Double">-20.4</d:decimalval>
> <d:timeval m:type="TimeOfDay">00:00:04</d:timeval>
> <d:dateval m:type="Date">2004-04-04</d:dateval>
> <d:timestampval m:type="DateTimeOffset">2004-01-01T00:00:04Z</d:timestampval>
> <d:clobval m:type="Binary">Y2xvYl92YWx1ZV8wMDAwNA==</d:clobval>
> </m:properties>
> </content>
> </entry>
> {code}
> \[3\]
> POST http://localhost:8080/odata4/olingo_basic/Source/PostTable(4)
> \[4\]
> Content-type: application/xml
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (TEIID-3776) Teiid throws NPE if query contains AVG function on varchar type
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3776?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3776:
------------------------------------------------
Filip Elias <felias(a)redhat.com> changed the Status of [bug 1272975|https://bugzilla.redhat.com/show_bug.cgi?id=1272975] from VERIFIED to CLOSED
> Teiid throws NPE if query contains AVG function on varchar type
> ---------------------------------------------------------------
>
> Key: TEIID-3776
> URL: https://issues.jboss.org/browse/TEIID-3776
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7.1.6_2
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
> Fix For: 8.12.1, 8.13
>
>
> Execution of this query ends with NPE in Teiid:
> SELECT stringnum FROM bqt1.smalla GROUP BY stringnum HAVING avg(stringnum) = '1'
> Expected result:
> Exception similar to - org.teiid.api.exception.query.QueryValidatorException: TEIID30492 The aggregate function AVG cannot be used with non-numeric expressions: AVG(BQT1.SmallA.StringNum)
> Actual result:
> {code:text}
> 12:27:32,829 DEBUG [org.teiid.TRANSPORT] (New I/O worker #7) processing message:MessageHolder: key=619 contents=Invoke interface org.teiid.client.DQP.executeRequest
> 12:27:32,830 DEBUG [org.teiid.PROCESSOR] (Worker52_QueryProcessorQueue378) Request Thread r77C2X0C5Gwa.10 with state NEW
> 12:27:32,830 DEBUG [org.teiid.PROCESSOR] (Worker52_QueryProcessorQueue378) r77C2X0C5Gwa.10 Non-cachable command.
> 12:27:32,830 DEBUG [org.teiid.PROCESSOR] (Worker52_QueryProcessorQueue378) r77C2X0C5Gwa.10 executing SELECT stringnum FROM bqt1.smalla GROUP BY stringnum HAVING avg(stringnum) = '1'
> 12:27:32,831 ERROR [org.teiid.PROCESSOR] (Worker52_QueryProcessorQueue378) TEIID30019 Unexpected exception for request r77C2X0C5Gwa.10: java.lang.NullPointerException
> at org.teiid.query.resolver.util.ResolverVisitor.resolveCompareCriteria(ResolverVisitor.java:767) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.resolver.util.ResolverVisitor.visit(ResolverVisitor.java:248) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.sql.lang.CompareCriteria.acceptVisitor(CompareCriteria.java:126) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.sql.navigator.AbstractNavigator.visitVisitor(AbstractNavigator.java:54) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.sql.navigator.PreOrPostOrderNavigator.postVisitVisitor(PreOrPostOrderNavigator.java:61) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.resolver.command.SimpleQueryResolver$QueryResolverVisitor.postVisitVisitor(SimpleQueryResolver.java:197) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.sql.navigator.PreOrPostOrderNavigator.visit(PreOrPostOrderNavigator.java:135) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.sql.lang.CompareCriteria.acceptVisitor(CompareCriteria.java:126) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.sql.navigator.AbstractNavigator.visitNode(AbstractNavigator.java:63) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.resolver.command.SimpleQueryResolver$QueryResolverVisitor.visit(SimpleQueryResolver.java:214) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.resolver.command.SimpleQueryResolver.resolveCommand(SimpleQueryResolver.java:69) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.resolver.QueryResolver.resolveCommand(QueryResolver.java:271) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.query.resolver.QueryResolver.resolveCommand(QueryResolver.java:124) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.dqp.internal.process.Request.resolveCommand(Request.java:260) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.dqp.internal.process.Request.generatePlan(Request.java:369) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.dqp.internal.process.Request.processRequest(Request.java:435) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.dqp.internal.process.RequestWorkItem.processNew(RequestWorkItem.java:613) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:315) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:254) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:274) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_40]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40]
> 12:27:32,832 DEBUG [org.teiid.PROCESSOR] (Worker52_QueryProcessorQueue378) java.lang.NullPointerException Sending error to client r77C2X0C5Gwa.10
> 12:27:32,833 DEBUG [org.teiid.TRANSPORT] (Worker52_QueryProcessorQueue378) send message: MessageHolder: key=619 contents=ResultsMessage rowCount=0 finalRow=-1
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (TEIID-3933) Accumulo translator: problem comparing number literals
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3933?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3933:
------------------------------------------------
Filip Elias <felias(a)redhat.com> changed the Status of [bug 1301665|https://bugzilla.redhat.com/show_bug.cgi?id=1301665] from VERIFIED to CLOSED
> Accumulo translator: problem comparing number literals
> ------------------------------------------------------
>
> Key: TEIID-3933
> URL: https://issues.jboss.org/browse/TEIID-3933
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.3
> Reporter: Jan Stastny
> Assignee: Ramesh Reddy
> Fix For: 9.0, 8.12.5
>
>
> When accessing Accumulo instance using accumulo translator with table DDL defined in the model's metadata, there are problems filtering the output in from clause.
> For example, when there is a comparison between a column of type long with literal value 3, an exception, whose cause is below, is thrown on accumulo's side:
> {code:sql}
> SELECT * FROM accumulo.SmallA WHERE LongNum>3
> {code}
> {code:plain}
> Caused by: java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long
> at java.lang.Long.compareTo(Long.java:50)
> at org.teiid.query.sql.symbol.Constant$2.compare(Constant.java:99)
> at org.teiid.query.eval.Evaluator.compare(Evaluator.java:645)
> at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:373)
> at org.teiid.query.eval.Evaluator.internalEvaluateTVL(Evaluator.java:237)
> at org.teiid.query.eval.Evaluator.evaluateTVL(Evaluator.java:226)
> at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:220)
> at org.teiid.translator.accumulo.EvaluatorIterator.acceptRow(EvaluatorIterator.java:229)
> at org.teiid.translator.accumulo.EvaluatorIterator.filter(EvaluatorIterator.java:184)
> at org.teiid.translator.accumulo.EvaluatorIterator.prepKeys(EvaluatorIterator.java:180)
> at org.teiid.translator.accumulo.EvaluatorIterator.seek(EvaluatorIterator.java:159)
> at org.apache.accumulo.core.iterators.WrappingIterator.seek(WrappingIterator.java:101)
> at org.apache.accumulo.core.iterators.user.VersioningIterator.seek(VersioningIterator.java:81)
> at org.apache.accumulo.core.iterators.system.SourceSwitchingIterator.readNext(SourceSwitchingIterator.java:116)
> at org.apache.accumulo.core.iterators.system.SourceSwitchingIterator.seek(SourceSwitchingIterator.java:168)
> at org.apache.accumulo.server.tabletserver.Tablet.nextBatch(Tablet.java:1737)
> at org.apache.accumulo.server.tabletserver.Tablet.access$3200(Tablet.java:152)
> at org.apache.accumulo.server.tabletserver.Tablet$Scanner.read(Tablet.java:1879)
> at org.apache.accumulo.server.tabletserver.TabletServer$ThriftClientHandler$NextBatchTask.run(TabletServer.java:945)
> at org.apache.accumulo.trace.instrument.TraceRunnable.run(TraceRunnable.java:47)
> {code}
> but when I provide a value higher, than can be saved in integer, thus the type of the literal is inferred as long, the query runs as expected.
> {code:sql}
> SELECT * FROM accumulo.SmallA WHERE LongNum>30000000000000000000
> {code}
> Similar problems I had with
> ||Column type||Literal||Inferred type||Rootcause message||
> |long|3|Integer|java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long|
> |biginteger|3|Integer|java.lang.ClassCastException: java.lang.Integer cannot be cast to java.math.BigInteger|
> |double|3.0|BigDecimal|java.lang.ClassCastException: java.math.BigDecimal cannot be cast to java.lang.Double|
> |float|3.0|BigDecimal|java.lang.ClassCastException: java.math.BigDecimal cannot be cast to java.lang.Float|
> rest of the cause's stacktrace look the same.
> In Squirrel I get:
> {code:plain}
> TEIID30504 Remote org.teiid.core.TeiidProcessingException: TEIID30504 node-one: Error on server 127.0.0.1:9997
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (TEIID-3983) External Materialization MATVIEW_ONERROR_ACTION WAIT problem
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-3983?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-3983:
------------------------------------------------
Filip Elias <felias(a)redhat.com> changed the Status of [bug 1311414|https://bugzilla.redhat.com/show_bug.cgi?id=1311414] from VERIFIED to CLOSED
> External Materialization MATVIEW_ONERROR_ACTION WAIT problem
> ------------------------------------------------------------
>
> Key: TEIID-3983
> URL: https://issues.jboss.org/browse/TEIID-3983
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.12.5
> Reporter: Jan Stastny
> Assignee: Steven Hawkins
> Fix For: 9.0, 8.12.5, 8.13.2
>
>
> When using "teiid_rel:MATVIEW_ONERROR_ACTION" 'WAIT' option in materialized view definition, there's problem with blocked request.
> The blocked request is the one, that triggered the materialized view's loading (first query on the defined materialized view). After such request, one can observe, that the query execution doesn't end, but hangs.
> Meanwhile while examining the contents of 'status' table in the underlying database, the LoadNumber column's value increases regularly according to the defined ttl. Moreover the 'LOADSTATE' column changes from LOADING to LOADED in similar manner. The materialized table is populated with correct data. From this I assume, materialization is set up correctly.
> During the wait, when logging set to DEBUG, there appears regularly, apart from the logs about refreshing the mat view, this entry:
> {code:plain}
> [32m09:14:52,151 DEBUG [org.teiid.PROCESSOR] (Worker0_QueryProcessorQueue2695) Request Thread 87XzBpSzkyk4.0 with state PROCESSING
> [32m09:14:52,151 DEBUG [org.teiid.PROCESSOR] (Worker0_QueryProcessorQueue2695) Request Thread 87XzBpSzkyk4.0 - processor blocked
> {code}
> The log appears in 'ttl' determined intervals, each time after materialized table loading related entries.
> The thread mentioned is the one created after the original query execution was initiated.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (TEIID-4062) OData - $crossjoin fails due to missing class
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-4062?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-4062:
------------------------------------------------
Filip Elias <felias(a)redhat.com> changed the Status of [bug 1316504|https://bugzilla.redhat.com/show_bug.cgi?id=1316504] from VERIFIED to CLOSED
> OData - $crossjoin fails due to missing class
> ---------------------------------------------
>
> Key: TEIID-4062
> URL: https://issues.jboss.org/browse/TEIID-4062
> Project: Teiid
> Issue Type: Sub-task
> Components: OData
> Reporter: Juraj Duráni
> Assignee: Ramesh Reddy
> Fix For: 9.0, 8.12.5
>
>
> *URL:* http://localhost:8080/odata4/olingo_basic/Source/$crossjoin(PutTable,Dele...
> *Missing dependency:* com.fasterxml.jackson
> *Error:*
> {code:plain}
> 11:04:51,047 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/odata4].[odata4]] (http-/127.0.0.1:8080-2) JBWEB000236: Servlet.service() for servlet odata4 threw exception: java.lang.ClassNotFoundException: com.fasterxml.jackson.core.JsonFactory from [Module "org.jboss.teiid.olingo:main" from local module loader @7c53a9eb (finder: local module finder @ed17bee (roots: /home/jdurani/redhat/tests/functional_testing/workdir_olingo/modules,/home/jdurani/redhat/tests/functional_testing/workdir_olingo/modules/system/layers/dv,/home/jdurani/redhat/tests/functional_testing/workdir_olingo/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.teiid.olingo.TeiidODataJsonSerializer.complexCollection(TeiidODataJsonSerializer.java:53) [teiid-olingo-8.12.5.redhat-2.jar:8.12.5.redhat-2]
> at org.teiid.olingo.EdmComplexResponse.writeComplexType(EdmComplexResponse.java:73) [teiid-olingo-8.12.5.redhat-2.jar:8.12.5.redhat-2]
> at org.teiid.olingo.service.TeiidServiceHandler.sendResults(TeiidServiceHandler.java:317) [teiid-olingo-8.12.5.redhat-2.jar:8.12.5.redhat-2]
> at org.teiid.olingo.service.TeiidServiceHandler.crossJoin(TeiidServiceHandler.java:834) [teiid-olingo-8.12.5.redhat-2.jar:8.12.5.redhat-2]
> at org.apache.olingo.server.core.requests.DataRequest$CrossJoinRequest.execute(DataRequest.java:692)
> at org.apache.olingo.server.core.requests.DataRequest.execute(DataRequest.java:245)
> at org.apache.olingo.server.core.ServiceDispatcher.execute(ServiceDispatcher.java:117)
> at org.apache.olingo.server.core.OData4HttpHandler.process(OData4HttpHandler.java:65)
> at org.teiid.olingo.web.ODataServlet.service(ODataServlet.java:50) [teiid-olingo-8.12.5.redhat-2.jar:8.12.5.redhat-2]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.teiid.olingo.web.ODataFilter.doFilter(ODataFilter.java:194) [teiid-olingo-8.12.5.redhat-2.jar:8.12.5.redhat-2]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.4.Final-redhat-4.jar:7.5.4.Final-redhat-4]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0-internal]
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (TEIID-4273) With clause used in evaluatable subquery in a fully pushed user query is seen as missing temp table
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-4273?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on TEIID-4273:
------------------------------------------------
Filip Elias <felias(a)redhat.com> changed the Status of [bug 1347311|https://bugzilla.redhat.com/show_bug.cgi?id=1347311] from VERIFIED to CLOSED
> With clause used in evaluatable subquery in a fully pushed user query is seen as missing temp table
> ---------------------------------------------------------------------------------------------------
>
> Key: TEIID-4273
> URL: https://issues.jboss.org/browse/TEIID-4273
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.1, 8.12.5, 8.7.7.6_2, 9.0.1
>
>
> A query such as:
> WITH qry_0 as /\*+ no_inline */ (SELECT e2 AS a1, e1 as str FROM pm1.g1 AS t), qry_1 as /\*+ no_inline */ (SELECT 'b' AS a1) select (select a1 || 'a' from qry_1) as x, a1 from qry_0
> where the projected scalar subquery cannot be pushed down, but the rest of the query can will result in the with plan for qry_1 not being associated with the parent RelationalPlan and results in an exception that the temporary table cannot be found. This does not occur if the clause is inlined (9.0+).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months