[JBoss JIRA] (TEIID-5174) Filter internal constructs from oracle metadata
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5174?page=com.atlassian.jira.plugin... ]
Work on TEIID-5174 started by Steven Hawkins.
---------------------------------------------
> Filter internal constructs from oracle metadata
> -----------------------------------------------
>
> Key: TEIID-5174
> URL: https://issues.jboss.org/browse/TEIID-5174
> Project: Teiid
> Issue Type: Quality Risk
> Components: JDBC Connector
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 10.1
>
>
> Even with the import table types set to TABLE, an Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 accessed with the 12.1.0.1.0 driver will contain internal tables which will cause the deployment to error:
> TEIID31071 Invalid table; Table oracleModel.HS_PARTITION_COL_NAME has no columns defined
> It would be good if these were filtered by default. The workaround is to specify a schema or regex to prevent such tables from being imported.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (TEIID-5161) Push down rand() function
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5161?page=com.atlassian.jira.plugin... ]
Work on TEIID-5161 started by Steven Hawkins.
---------------------------------------------
> Push down rand() function
> -------------------------
>
> Key: TEIID-5161
> URL: https://issues.jboss.org/browse/TEIID-5161
> Project: Teiid
> Issue Type: Quality Risk
> Components: JDBC Connector, Query Engine
> Affects Versions: 9.3.4
> Environment: teiid-9.3.4 on WildFly Full 10.0.0.Final (WildFly Core 2.0.10.Final)
> Reporter: dalex dalex
> Assignee: Steven Hawkins
> Fix For: 10.1
>
>
> As per discussion within TEIID-5153 we should push down rand() function where ever it seems to be missing. But first of all the function should be pushed down for at least PostgreSQL, MySQL, MSSQL and Oracle databases.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (TEIID-5134) Build Changes
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5134?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5134:
---------------------------------------
Switched the main download to reference the latest weekly build snapshots for the unstable version - http://teiid.jboss.org/downloads/
> Build Changes
> -------------
>
> Key: TEIID-5134
> URL: https://issues.jboss.org/browse/TEIID-5134
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 10.1
>
>
> For 10.1 and later I propose that we convert to an 8-10 week cycle - with no pre-releases - so that we can drop the usage of the Alpha, Beta, etc. designations. We'll encourage people to follow the weekly snapshot builds instead.
> We will have to better manage when changes are pulled in, such as how we waited for the WildFly 11 Final.
> Another goal is to have the build fully automated with website updates TEIID-5015
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (TEIID-5168) PrestoDB translator - Convert to float not pushed correctly
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5168?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-5168:
----------------------------------
Fix Version/s: 10.0.2
(was: 10.0.1)
> PrestoDB translator - Convert to float not pushed correctly
> -----------------------------------------------------------
>
> Key: TEIID-5168
> URL: https://issues.jboss.org/browse/TEIID-5168
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.12.x-6.4
> Reporter: Andrej Šmigala
> Assignee: Steven Hawkins
> Fix For: 10.1, 10.0.2
>
>
> Running query such as
> {code:sql}
> SELECT StringKey, (convert(StringKey, float)+3) FROM BQT1.SmallA
> {code}
> Fails with the following exception:
> {noformat}
> org.teiid.translator.jdbc.JDBCExecutionException: 1 TEIID11008:TEIID11004 Error executing statement(s): [SQL: SELECT g_0.stringkey AS c_0, (g_0.stringkey + 3.0) AS c_1 FROM smalla AS g_0 LIMIT 100]
> at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:131) [translator-jdbc-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:363)
> at sun.reflect.GeneratedMethodAccessor171.invoke(Unknown Source) [:1.8.0_141]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_141]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_141]
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211)
> at com.sun.proxy.$Proxy80.execute(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:306)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:112)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_141]
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:284)
> 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:1149) [rt.jar:1.8.0_141]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_141]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_141]
> Caused by: java.sql.SQLException: Query failed (#20171121_110032_00034_8zhqn): line 1:45: '+' cannot be applied to varchar(10), double
> at com.facebook.presto.jdbc.PrestoResultSet.resultsException(PrestoResultSet.java:1799)
> at com.facebook.presto.jdbc.PrestoResultSet.getColumns(PrestoResultSet.java:1747)
> at com.facebook.presto.jdbc.PrestoResultSet.<init>(PrestoResultSet.java:125)
> at com.facebook.presto.jdbc.PrestoStatement.execute(PrestoStatement.java:212)
> at com.facebook.presto.jdbc.PrestoStatement.executeQuery(PrestoStatement.java:69)
> at org.jboss.jca.adapters.jdbc.WrappedStatement.executeQuery(WrappedStatement.java:344)
> at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:119) [translator-jdbc-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7]
> ... 17 more
> {noformat}
> The query is translated as (note missing convert)
> {code:sql}
> SELECT g_0.stringkey AS c_0, (g_0.stringkey + 3.0) AS c_1 FROM smalla AS g_0
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (TEIID-5168) PrestoDB translator - Convert to float not pushed correctly
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5168?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5168.
-----------------------------------
Fix Version/s: 10.0.1
Resolution: Done
Updated the translator to push down additional types based upon the version, and to not allow the pushdown for older versions.
> PrestoDB translator - Convert to float not pushed correctly
> -----------------------------------------------------------
>
> Key: TEIID-5168
> URL: https://issues.jboss.org/browse/TEIID-5168
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 8.12.x-6.4
> Reporter: Andrej Šmigala
> Assignee: Steven Hawkins
> Fix For: 10.1, 10.0.1
>
>
> Running query such as
> {code:sql}
> SELECT StringKey, (convert(StringKey, float)+3) FROM BQT1.SmallA
> {code}
> Fails with the following exception:
> {noformat}
> org.teiid.translator.jdbc.JDBCExecutionException: 1 TEIID11008:TEIID11004 Error executing statement(s): [SQL: SELECT g_0.stringkey AS c_0, (g_0.stringkey + 3.0) AS c_1 FROM smalla AS g_0 LIMIT 100]
> at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:131) [translator-jdbc-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:363)
> at sun.reflect.GeneratedMethodAccessor171.invoke(Unknown Source) [:1.8.0_141]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_141]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_141]
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211)
> at com.sun.proxy.$Proxy80.execute(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:306)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:112)
> at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_141]
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:284)
> 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:1149) [rt.jar:1.8.0_141]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_141]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_141]
> Caused by: java.sql.SQLException: Query failed (#20171121_110032_00034_8zhqn): line 1:45: '+' cannot be applied to varchar(10), double
> at com.facebook.presto.jdbc.PrestoResultSet.resultsException(PrestoResultSet.java:1799)
> at com.facebook.presto.jdbc.PrestoResultSet.getColumns(PrestoResultSet.java:1747)
> at com.facebook.presto.jdbc.PrestoResultSet.<init>(PrestoResultSet.java:125)
> at com.facebook.presto.jdbc.PrestoStatement.execute(PrestoStatement.java:212)
> at com.facebook.presto.jdbc.PrestoStatement.executeQuery(PrestoStatement.java:69)
> at org.jboss.jca.adapters.jdbc.WrappedStatement.executeQuery(WrappedStatement.java:344)
> at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:119) [translator-jdbc-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7]
> ... 17 more
> {noformat}
> The query is translated as (note missing convert)
> {code:sql}
> SELECT g_0.stringkey AS c_0, (g_0.stringkey + 3.0) AS c_1 FROM smalla AS g_0
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (TEIID-5176) Postgresql ODBC driver converts {fn CONCAT()} calls to a "textcat()" function
by Debbie Steigner (JIRA)
Debbie Steigner created TEIID-5176:
--------------------------------------
Summary: Postgresql ODBC driver converts {fn CONCAT()} calls to a "textcat()" function
Key: TEIID-5176
URL: https://issues.jboss.org/browse/TEIID-5176
Project: Teiid
Issue Type: Bug
Reporter: Debbie Steigner
Assignee: Steven Hawkins
Customer is using tableau which converts to a SQL statement that includes nested concat function calls like [1]. The Postgresql ODBC driver appears to interpret those {fn CONCAT()} calls and converts to a "textcat()" function, which then results in a parsing error from Teiid since we don't support a textcat() function.
[1] {fn CONCAT({fn CONCAT("TripSourceHotelBooking"."HotelCity", ', ')}, "TripSourceHotelBooking"."HotelCountry")} AS "Calculation_984036526439337984",
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (TEIID-5097) Cannot run time-based queries against Osisoft PI
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5097?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5097:
---------------------------------------
So for now the workaround is to add the source / pushdown function to the pi source model:
create function to_interval(param string) returns timestamp options ("teiid_rel:native-query" $1)
> Cannot run time-based queries against Osisoft PI
> ------------------------------------------------
>
> Key: TEIID-5097
> URL: https://issues.jboss.org/browse/TEIID-5097
> Project: Teiid
> Issue Type: Quality Risk
> Components: JDBC Connector
> Affects Versions: 8.12.x-6.4
> Reporter: Andrej Šmigala
> Fix For: 10.1
>
>
> Osisoft PI supports a relative time literals syntax, e.g.
> {code:sql}
> select * from dvqe.Data.Archive a where a.time between '*-14d' and '*'
> {code}
> will select all data between right now and 14 days ago, and
> {code:sql}
> select * from dvqe.Data.Archive a where a.time > 'y'
> {code}
> will select all data after yesterday midnight.
> The string literals are converted to time values in the PI Server
> Running the same queries through teiid however returns incorrect results, because teiid pushes a cast to string on the Time column, which results in string comparison on the datasource:
> {code:sql|title=Pushed query}
> SELECT TOP 100 cast(g_0.[ElementAttributeID] as String), g_0.[Time] AS c_1, g_0.[Value] AS c_2, g_0.[ValueInt] AS c_3, g_0.
> [ValueDbl] AS c_4, g_0.[ValueStr] AS c_5, cast(g_0.[ValueGuid] as String), g_0.[ValueDateTime] AS c_7, g_0.[Status] AS c_8, g_0.[Annotated] AS c_9, g_0.[IsGood] A
> S c_10, g_0.[Questionable] AS c_11, g_0.[Substituted] AS c_12 FROM [dvqe].[Data].[Archive] AS g_0 WHERE cast(g_0.[Time] AS String) > 'y'
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (TEIID-4920) [Deployment model] Worker thread pool could be ready to handle VDB requests before VDB deployment has finished
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4920?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-4920.
---------------------------------
> [Deployment model] Worker thread pool could be ready to handle VDB requests before VDB deployment has finished
> --------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-4920
> URL: https://issues.jboss.org/browse/TEIID-4920
> Project: Teiid
> Issue Type: Bug
> Components: Embedded, JDBC Connector, VDB
> Affects Versions: 8.10
> Reporter: Krum Bakalsky
> Assignee: Steven Hawkins
> Priority: Minor
>
> Our application uses Embedded Teiid server, and upon starting up it first creates and starts the Teiid server, and then performs a VDB deployment on top of it:
> {code}
> void startApplication() {
> createEmbeddedServer(); // 1
> deployVDB(); // 2
> }
> createEmbeddedServer() method does the following:
> {
> EmbeddedConfiguration ec = createEmbeddedConfiguration();
> EmbeddedServer teiidServer = createEmbeddedTeiidServer();
> teiidServer.start(ec);
> }
> {code}
> Step 2 - deployVDB() method - takes a while to complete, at minimum around 6-8 seconds. However, executing step 1 (creating and starting the embedded server) already creates its worker thread pool (the DQP pool), that is ready to serve incoming JDBC calls.
> One of the reasons why we chose to perform these steps in that very order, is because of the [deployVDB|http://grepcode.com/file/repository.jboss.org/nexus/content/rep...] method: it first checks if the server is started and fails if that is not the case. So the order is somehow implied by the way Teiid deployment works.
> This particular way of using Teiid is vulnerable to the following race condition: if client JDBC calls start coming while step 2 is not yet completed (VDB deployment is still in progress), then they will fail since the VDB metadata will be null:
> {code}
> 2017-02-14 11:18:12,250 ERROR org.teiid.PROCESSOR: TEIID30019 Unexpected exception for request <request_id>
> org.teiid.core.TeiidComponentException: TEIID30489 Unable to load metadata for VDB <vdb_name>.
> at org.teiid.dqp.internal.process.Request.initMetadata(Request.java:191)
> at org.teiid.dqp.internal.process.Request.processRequest(Request.java:436)
> at org.teiid.dqp.internal.process.RequestWorkItem.processNew(RequestWorkItem.java:627)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:326)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:265)
> 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)
> {code}
> Please advise of what is the safest way to achieve VDB deployment + server start, and in what order.
> *Note*: Please note that this is probably not best categorized as a bug, but rather some glitch in the behavior of Embedded Teiid, or maybe even some misunderstanding about how deployment should be done w.r.t starting the embedded server.
> I am assigning a minor priority since the impact of this problem is relatively small and limited - clients will be affected until VDB deployment is in progress.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months