[JBoss JIRA] (TEIID-5446) Retrieving clob values from Exasol prints stacktrace to server log
by Andrej Šmigala (JIRA)
Andrej Šmigala created TEIID-5446:
-------------------------------------
Summary: Retrieving clob values from Exasol prints stacktrace to server log
Key: TEIID-5446
URL: https://issues.jboss.org/browse/TEIID-5446
Project: Teiid
Issue Type: Bug
Components: JDBC Connector
Affects Versions: 11.1, 8.12.15.6_4
Reporter: Andrej Šmigala
Assignee: Steven Hawkins
In Exasol, CLOB is [an alias|https://www.exasol.com/support/secure/attachment/49848/EXASOL_User_...] for VARCHAR. When querying a foreign table with a CLOB column defined as
{code:sql}
ObjectValue clob OPTIONS (NATIVE_TYPE 'varchar(4000)', NAMEINSOURCE 'objectvalue'))
{code},
an exception is logged in the server output for each row.
The query itself finishes successfully and the returned results are correct.
{noformat}
12:44:20,959 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr java.lang.Throwable
12:44:20,960 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr at com.exasol.jdbc.Column.type_error(Column.java:26)
12:44:20,960 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr at com.exasol.jdbc.Column.getClob(Column.java:137)
12:44:20,960 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr at com.exasol.jdbc.EXAResultSet.getClob(EXAResultSet.java:686)
12:44:20,960 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr at org.jboss.jca.adapters.jdbc.WrappedResultSet.getClob(WrappedResultSet.java:1060)
12:44:20,960 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr at org.teiid.translator.jdbc.JDBCExecutionFactory.retrieveValue(JDBCExecutionFactory.java:1146)
12:44:20,960 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr at org.teiid.translator.jdbc.JDBCQueryExecution.next(JDBCQueryExecution.java:340)
12:44:20,960 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.handleBatch(ConnectorWorkItem.java:455)
12:44:20,960 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.more(ConnectorWorkItem.java:241)
12:44:20,960 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
12:44:20,960 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
12:44:20,960 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
12:44:20,960 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr at java.lang.reflect.Method.invoke(Method.java:498)
12:44:20,960 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:229)
12:44:20,960 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr at com.sun.proxy.$Proxy36.more(Unknown Source)
12:44:20,960 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:305)
12:44:20,960 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108)
12:44:20,960 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:104)
12:44:20,960 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr at java.util.concurrent.FutureTask.run(FutureTask.java:266)
12:44:20,960 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:61)
12:44:20,960 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:277)
12:44:20,960 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:115)
12:44:20,960 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:206)
12:44:20,960 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
12:44:20,960 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
12:44:20,960 ERROR [stderr] (Worker6_QueryProcessorQueue42) axblivLlwkmr at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (TEIID-5343) Enable absolute URI on context definition of EntitySets when using ODATA
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-5343?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-5343:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1617906
Bugzilla Update: Perform
> Enable absolute URI on context definition of EntitySets when using ODATA
> ------------------------------------------------------------------------
>
> Key: TEIID-5343
> URL: https://issues.jboss.org/browse/TEIID-5343
> Project: Teiid
> Issue Type: Enhancement
> Components: OData
> Affects Versions: 10.2.1
> Reporter: Rafael Sampaio
> Assignee: Ramesh Reddy
> Fix For: 11.1
>
>
> Hi all you TEIID guys.
> As reported on [OLINGO-1025|https://issues.apache.org/jira/browse/OLINGO-1025], integrating to MS OData consumers (ie. PowerBI/PowerQuery) gives the "should be an absolute Uri" error.
> The proposed solution in the JIRA is implementing a Processor for any given EntityType. Browsing through the code i see TEIID uses the ServiceHandler approach, instead of processor and it also has a Custom JSON Odata Serializer.
> I see that the Default JSON serializer, when serializing entity collections uses the ContextURL to generate the context metadata for the EntityCollection, but by default it does not contain the service root, since it comes from static DataRequest.buildEntitySetContextURL(olingo) method.
> Would be nice if we could choose this behavior through a init param in the odata deployment.
> Thanks in advance.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (TEIID-5445) Atomic block is ignored when working with execute immediate command
by dalex dalex (JIRA)
dalex dalex created TEIID-5445:
----------------------------------
Summary: Atomic block is ignored when working with execute immediate command
Key: TEIID-5445
URL: https://issues.jboss.org/browse/TEIID-5445
Project: Teiid
Issue Type: Bug
Components: Query Engine
Affects Versions: 10.2
Environment: teiid-10.2.0 on WildFly Full 11.0.0.Final (WildFly Core 3.0.8.Final)
Reporter: dalex dalex
Assignee: Steven Hawkins
Priority: Blocker
When calling in atomic block a proc which is throwing an exception after updating some rows these changed rows won't be rolled back. That is running the following query:
{code:sql}
begin atomic
call test_upd.upd();
end ;;
{code}
all changes done in the test_upd.upd virtual procedure won't be rolled back in case of a thrown exception there. If I'm not mistaken such behavior was introduced in scope of TEIID-4504 issue (after introducing the Program.instructionsRequireTransaction method).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (TEIID-5444) Upgrade to Olingo-4.5
by Ramesh Reddy (JIRA)
Ramesh Reddy created TEIID-5444:
-----------------------------------
Summary: Upgrade to Olingo-4.5
Key: TEIID-5444
URL: https://issues.jboss.org/browse/TEIID-5444
Project: Teiid
Issue Type: Task
Components: Build/Kits
Reporter: Ramesh Reddy
Assignee: Steven Hawkins
Fix For: 11.1
Upgrade the olingo library to latest 4.5 version
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (TEIID-4455) Impala Translator - Change planning step for from_unixtime() pushdown
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-4455?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-4455:
---------------------------------
Fix Version/s: 8.12.15.6_4
> Impala Translator - Change planning step for from_unixtime() pushdown
> ---------------------------------------------------------------------
>
> Key: TEIID-4455
> URL: https://issues.jboss.org/browse/TEIID-4455
> Project: Teiid
> Issue Type: Feature Request
> Components: JDBC Connector
> Reporter: Don Krapohl
> Assignee: Kylin Soong
> Priority: Minor
> Labels: Impala_Translator
> Fix For: 9.2, 8.12.15.6_4
>
>
> Impala and Teiid both have from_unixtime() functions and per the forum reference the mapping to timestampadd() appears to come before the test for pushdown support of the impala native function.
> As a query request we require the impala from_unixtime() function be executed instead of the Teiid-native version.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (TEIID-5394) Define how to utilize multiple vdbs
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-5394?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5394:
-------------------------------------
> If you are suggesting to do that at runtime, that's not much different than what I'm suggesting.
I am saying if you need to separate ddl files per schema to support import schema, let's put that as a restriction, no reason to be flexible.
> You may want to alter the current behavior. See the .vdb from rdbms-as-datasource, it will contain the yaml as described above.
You are correct, it is picking up resources folder. I have to test if that is needed or could be omitted. Even if we did, that should be served as a configuration template as the values for most properties should flow in from environment variables.
> Also a .ddl file is not covered by the maven plugin logic. Was that intentional?
Are you asking for top-level VDB? if yes, that is true, I did not put in support for .ddl initially was not sure if that worked in zipped archive
> Define how to utilize multiple vdbs
> -----------------------------------
>
> Key: TEIID-5394
> URL: https://issues.jboss.org/browse/TEIID-5394
> Project: Teiid
> Issue Type: Sub-task
> Components: Build/Kits
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 11.1
>
>
> Perhaps to support vdb imports, we should define how a build can incorporate multiple vdbs.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (TEIID-5443) Using RAND() function in a column mask errors on temp table creation
by Debbie Steigner (JIRA)
Debbie Steigner created TEIID-5443:
--------------------------------------
Summary: Using RAND() function in a column mask errors on temp table creation
Key: TEIID-5443
URL: https://issues.jboss.org/browse/TEIID-5443
Project: Teiid
Issue Type: Bug
Components: Server
Affects Versions: 8.12.14.6_4
Reporter: Debbie Steigner
Assignee: Steven Hawkins
Column masking with RAND() tries to create a temp table and errors:
09:47:47,601 ERROR [org.teiid.PROCESSOR] (Worker20_QueryProcessorQueue88) TEIID30019 Unexpected exception for request IAgYDrdYXFRm.30: org.teiid.core.TeiidComponentException: TEIID30091 org.teiid.api.exception.query.QueryResolverException: TEIID30091 Cannot create group 'sec AS sec__1' with multiple columns named 'expr'
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (TEIID-5440) Couchbase translator - LET usage prevents index scan
by Jan Stastny (JIRA)
[ https://issues.jboss.org/browse/TEIID-5440?page=com.atlassian.jira.plugin... ]
Jan Stastny commented on TEIID-5440:
------------------------------------
[~shawkins] I'll verify with the upstream fix and let you know.
> Couchbase translator - LET usage prevents index scan
> ----------------------------------------------------
>
> Key: TEIID-5440
> URL: https://issues.jboss.org/browse/TEIID-5440
> Project: Teiid
> Issue Type: Quality Risk
> Components: Misc. Connectors
> Affects Versions: 8.12.14.6_4
> Reporter: Jan Stastny
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 11.1
>
>
> Couchbase translator excesively uses LET clause(1) just for purpose of naming columns.
> That's not correct usage of LET clause and affects query execution in couchbase.
> Simple query
> {code:sql}
> SELECT IntKey FROM SmallA;
> {code}
> is being pushed as
> {code:sql}
> SELECT `$cb_c1_IntKey` c1 FROM `dvqe` `$cb_t1` LET `$cb_c1_IntKey` = `$cb_t1`.`intkey` WHERE `$cb_t1`.`type` = 'smalla'
> {code}
> Which is fine and index on `type` column is scanned on couchbase side.
> But when I issue query
> {code:sql}
> SELECT * FROM SmallA;
> {code}
> it is pushed as
> {code:sql}
> SELECT
> `$cb_c1_documentID` c1,
> `$cb_c2_FloatNum` c2,
> `$cb_c3_IntKey` c3,
> `$cb_c4_BigIntegerValue` c4,
> `$cb_c5_StringKey` c5,
> `$cb_c6_CharValue` c6,
> `$cb_c7_LongNum` c7,
> `$cb_c8_type` c8,
> `$cb_c9_DoubleNum` c9,
> `$cb_c10_ObjectValue` c10,
> `$cb_c11_ShortValue` c11,
> `$cb_c12_BigDecimalValue` c12,
> `$cb_c13_DateValue` c13,
> `$cb_c14_BooleanValue` c14,
> `$cb_c15_TimestampValue` c15,
> `$cb_c16_ByteNum` c16,
> `$cb_c17_StringNum` c17,
> `$cb_c18_TimeValue` c18,
> `$cb_c19_IntNum` c19
> FROM `dvqe` `$cb_t1`
> LET `$cb_c1_documentID` = META(`$cb_t1`).id,
> `$cb_c2_FloatNum` = `$cb_t1`.`floatnum`,
> `$cb_c3_IntKey` = `$cb_t1`.`intkey`,
> `$cb_c4_BigIntegerValue` = `$cb_t1`.`bigintegervalue`,
> `$cb_c5_StringKey` = `$cb_t1`.`stringkey`,
> `$cb_c6_CharValue` = `$cb_t1`.`charvalue`,
> `$cb_c7_LongNum` = `$cb_t1`.`longnum`,
> `$cb_c8_type` = `$cb_t1`.`type`,
> `$cb_c9_DoubleNum` = `$cb_t1`.`doublenum`,
> `$cb_c10_ObjectValue` = `$cb_t1`.`objectvalue`,
> `$cb_c11_ShortValue` = `$cb_t1`.`shortvalue`,
> `$cb_c12_BigDecimalValue` = `$cb_t1`.`bigdecimalvalue`,
> `$cb_c13_DateValue` = `$cb_t1`.`datevalue`,
> `$cb_c14_BooleanValue` = `$cb_t1`.`booleanvalue`,
> `$cb_c15_TimestampValue` = `$cb_t1`.`timestampvalue`,
> `$cb_c16_ByteNum` = `$cb_t1`.`bytenum`,
> `$cb_c17_StringNum` = `$cb_t1`.`stringnum`,
> `$cb_c18_TimeValue` = `$cb_t1`.`timevalue`,
> `$cb_c19_IntNum` = `$cb_t1`.`intnum`
> WHERE `$cb_c8_type` = 'smalla'
> {code}
> The way how WHERE criteria is being pushed (either column or LET variable reference) affects execution plan and prevents index scan in the latter case. (WHERE `$cb_t1`.`type` = 'smalla' vs. WHERE `$cb_c8_type` = 'smalla').
> (1) https://developer.couchbase.com/documentation/server/current/n1ql/n1ql-la...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (TEIID-5374) Allow for non-virtual dependent joins to be created over unions
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-5374?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-5374:
---------------------------------
Fix Version/s: 8.12.15.6_4
> Allow for non-virtual dependent joins to be created over unions
> ----------------------------------------------------------------
>
> Key: TEIID-5374
> URL: https://issues.jboss.org/browse/TEIID-5374
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 11.0, 10.3.2, 10.2.3, 8.12.15.6_4
>
>
> A simple structure like:
> {code}
> join
> access
> union
> access
> access
> {code}
> will reject creating a cost based dependent join over the union if the number of independent values seems too large for a virtual dependent join.
> A related issue is that TEIID-5020 introduced a regression when creating a dependent join that is eventually pushed over a union below an access node:
> {code}
> dependent select
> access
> set op
> ..
> {code}
> the logic attempts to move nested dependent select back above the access node - so that only a single dependent predicate exists - based upon the node that is created at a child. However if the child projects a literal into the dependent set criteria, then the result is invalid.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months