[JBoss JIRA] (TEIID-5096) Using /*+ MAKEDEP */ blocks the deploy proces when using DDL based vdb
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5096?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5096:
---------------------------------------
I'm still at a loss what is occurring here. Based upon your recent comments it doesn't even seem like it's necessarily related to makedep. The only special logic there is the use of regex pattern against the comment to determine the hint properties - but that is done with a thread-safe Matcher.
Is is possible to share anything else here - are you using the admin client or directly using the jboss cli? What is the full stacktrace you are getting at the client? Are there any other concurrent deployment operations? Are there network issues possible between where the cli client is running and the server?
In local testing I'm using an arquillian test that will do thousands of deployments of a ddl vdb either replacing or new version that contains thousands of views each with a makedep hint - without anything that resembles this issue.
> Using /*+ MAKEDEP */ blocks the deploy proces when using DDL based vdb
> ----------------------------------------------------------------------
>
> Key: TEIID-5096
> URL: https://issues.jboss.org/browse/TEIID-5096
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 9.3.3
> Reporter: Bram Gadeyne
> Assignee: Steven Hawkins
> Attachments: threaddump.txt
>
>
> Hi,
> I've created a vdb that is depoyed using a vdb-ddl.ddl file.
> The deployment just stops and returned no error message when adding the SQL part below. Subsequent deployments are not handles. It seems like the deployment process just hangs. The only way to resolve this was to stop the wildfly server, remove the latest added content from the standalone/data/content directory and restart wildfly.
> {code:sql}
> CREATE VIEW tv_retrieve_monvals(
> admissionid integer not null,
> VariableID integer not null,
> Datetime timestamp not null,
> Entertime timestamp not null,
> varvalue double not null,
> primary key (admissionid, VariableID, Datetime)
> )
> AS
> SELECT v.PatientID AS admissionid, v.VariableID, v.Datetime, v.Entertime, v."Value" AS varvalue
> FROM (
> SELECT mv.PatientID, mv.VariableID, mv.Datetime, mv.Entertime, mv."Value",
> ROW_NUMBER() OVER (PARTITION BY mv.PatientID, mv.VariableID, mv.Datetime ORDER BY mv.Entertime DESC) AS rang
> FROM izisprod.P_GeneralData AS gd
> INNER JOIN /*+ MAKEDEP */ izisprod.P_MonVals AS mv ON
> gd.PatientID = mv.PatientID AND
> bitand(mv.Status, 8) = 8 AND
> bitand(mv.Status, 2) <> 2
> WHERE gd.Status = 1 OR (gd.Status >= 4 AND gd.Status <> 5)
> UNION
> SELECT mv.PatientID, mv.VariableID, mv.Datetime, mv.Entertime, mv."Value",
> ROW_NUMBER() OVER (PARTITION BY mv.PatientID, mv.VariableID, mv.Datetime ORDER BY mv.Entertime DESC) AS rang
> FROM iziswh.P_GeneralData AS gd
> INNER JOIN /*+ MAKEDEP */ iziswh.P_MonVals AS mv ON
> gd.PatientID = mv.PatientID AND
> bitand(mv.Status, 8) = 8 AND
> bitand(mv.Status, 2) <> 2
> ) AS v
> WHERE v.rang = 1;
> {code}
> Removing the /*+ MAKDEP */ references resolves the issue.
> I've tried creating a small ddl script that uses /*+ MAKEDEP */ to reproduce this issue but this script does deploy so currently I can not make a small example.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months
[JBoss JIRA] (TEIID-5343) Enable absolute URI on context definition of EntitySets when using ODATA
by Rafael Sampaio (JIRA)
[ https://issues.jboss.org/browse/TEIID-5343?page=com.atlassian.jira.plugin... ]
Rafael Sampaio updated TEIID-5343:
----------------------------------
Description:
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.
was:
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, intead 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.
> 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: Steven Hawkins
>
> 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, 8 months
[JBoss JIRA] (TEIID-5343) Enable absolute URI on context definition of EntitySets when using ODATA
by Rafael Sampaio (JIRA)
Rafael Sampaio created TEIID-5343:
-------------------------------------
Summary: 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: Steven Hawkins
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, intead 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, 8 months
[JBoss JIRA] (TEIID-5341) Cannot extract time components from TIME column with Oracle
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5341?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5341.
-----------------------------------
Resolution: Done
The was already a dataawareextract modifier, but it was too limited. It has been updated to consider date and time types in general.
Obviously the intermediate cast to time isn't meaningful to the results in this case. If needed we can add a rewrite rule to remove it in situations like this.
> Cannot extract time components from TIME column with Oracle
> -----------------------------------------------------------
>
> Key: TEIID-5341
> URL: https://issues.jboss.org/browse/TEIID-5341
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.12.6_4
> Reporter: Jan Martiska
> Assignee: Steven Hawkins
> Fix For: 10.3
>
>
> This query against an Oracle-backed VDB:
> {noformat}
> SELECT hour(timevalue) FROM BQT1.SmallA
> {noformat}
> will fail with this error:
> {noformat}
> 13:16:42,493 WARN [org.teiid.CONNECTOR] (Worker9_QueryProcessorQueue157) Connector worker process failed for atomic-request=eiMf6Yh5oppn.9.0.25: org.teiid.translator.jdbc.JDBCExecutionException: 30076 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: [] SQL: SELECT c_0 FROM (SELECT EXTRACT(HOUR FROM case when g_0.timevalue is null then null else to_date('1970-01-01 ' || to_char(g_0.timevalue, 'HH24:MI:SS'), 'YYYY-MM-DD HH24:MI:SS') end) AS c_0 FROM smalla g_0 WHERE case when g_0.timevalue is null then null else to_date('1970-01-01 ' || to_char(g_0.timevalue, 'HH24:MI:SS'), 'YYYY-MM-DD HH24:MI:SS') end IS NOT NULL) WHERE ROWNUM <= 100]
> at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:131) [translator-jdbc-8.12.13.6_4-redhat-64-3.jar:8.12.13.6_4-redhat-64-3]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:361)
> at sun.reflect.GeneratedMethodAccessor170.invoke(Unknown Source) [:1.8.0_151]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_151]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_151]
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211)
> at com.sun.proxy.$Proxy79.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_151]
> 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_151]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_151]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_151]
> Caused by: java.sql.SQLException: ORA-30076: invalid extract field for extract source
> at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:450)
> at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:399)
> at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:1059)
> at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:522)
> at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:257)
> at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:587)
> at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:225)
> at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:53)
> at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:774)
> at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:925)
> at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1111)
> at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:4798)
> at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:4845)
> at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeQuery(OraclePreparedStatementWrapper.java:1501)
> at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:462)
> at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:123) [translator-jdbc-8.12.13.6_4-redhat-64-3.jar:8.12.13.6_4-redhat-64-3]
> ... 17 more
> {noformat}
> this seems to affect TIME columns which are converted from timestamps in the view model:
> {noformat}
> CREATE VIEW smalla (...)
> TimeValue time, (...) AS SELECT (...)
> convert(TimeValue, time) AS TimeValue
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months
[JBoss JIRA] (TEIID-5303) MongoDB translator issues with aggregate function expressions
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5303?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-5303:
----------------------------------
Fix Version/s: 10.x
(was: 10.3)
> MongoDB translator issues with aggregate function expressions
> -------------------------------------------------------------
>
> Key: TEIID-5303
> URL: https://issues.jboss.org/browse/TEIID-5303
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 10.x
>
>
> MongoDB queries involing expressions with aggregate functions in the select or having clauses will fail. It appears that another projection phase is needed to handling those computations as they are not valid in the group operation.
> For example, these result in exceptions:
> SELECT min(e1)+1, e2 FROM TIME_TEST GROUP BY e2
> SELECT min(e1), e2 FROM TIME_TEST GROUP BY e2 HAVING year(e2) + count(\*) = 2
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months
[JBoss JIRA] (TEIID-5303) MongoDB translator issues with aggregate function expressions
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5303?page=com.atlassian.jira.plugin... ]
Steven Hawkins reassigned TEIID-5303:
-------------------------------------
Assignee: (was: Steven Hawkins)
> MongoDB translator issues with aggregate function expressions
> -------------------------------------------------------------
>
> Key: TEIID-5303
> URL: https://issues.jboss.org/browse/TEIID-5303
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7
> Reporter: Steven Hawkins
> Fix For: 10.x
>
>
> MongoDB queries involing expressions with aggregate functions in the select or having clauses will fail. It appears that another projection phase is needed to handling those computations as they are not valid in the group operation.
> For example, these result in exceptions:
> SELECT min(e1)+1, e2 FROM TIME_TEST GROUP BY e2
> SELECT min(e1), e2 FROM TIME_TEST GROUP BY e2 HAVING year(e2) + count(\*) = 2
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months
[JBoss JIRA] (TEIID-5311) Sybase implicit Convertion of String value 'yyyy-MM-dd HH:mm' into a Date value Causes mismatches in JDV Date comparison
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5311?page=com.atlassian.jira.plugin... ]
Work on TEIID-5311 started by Steven Hawkins.
---------------------------------------------
> Sybase implicit Convertion of String value 'yyyy-MM-dd HH:mm' into a Date value Causes mismatches in JDV Date comparison
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-5311
> URL: https://issues.jboss.org/browse/TEIID-5311
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Reporter: Anu Saji
> Assignee: Steven Hawkins
> Priority: Minor
> Fix For: 10.3
>
> Attachments: eniqpreparser_v4.zip
>
>
> Sybase implicitly converts a String value 'yyyy-MM-dd HH:mm' into a Date value.
> This format is not standard and this conversion is specific to Sybase.
> As JDBC/Java standard, JDV implicitly converts
> 'yyyy-MM-dd HH:mm:ss' into a Timestamp value
> 'yyyy-MM-dd' into a Date value
> So JDV does not considered 'yyyy-MM-dd HH:mm' as a Date value and does not proceed to any implicit conversion. 'yyyy-MM-dd HH:mm' remains like a String value which partially matches with Date comparison
> Constraint
> We cannot modify the incoming query
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months
[JBoss JIRA] (TEIID-4520) Support for Exasol Connector
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4520?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-4520:
-------------------------------------
What it would mean is for downstream applications which sniff Teiid's DatabaseMetadata, would assume that Teiid returns HIGH order on the NULLs but in reality, we can not guarantee it by default. When the user does set it in the ORDER BY then we force the engine but not by default. Thus that setting is incorrect.
> Support for Exasol Connector
> ----------------------------
>
> Key: TEIID-4520
> URL: https://issues.jboss.org/browse/TEIID-4520
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors
> Affects Versions: 9.x
> Reporter: Van Halbert
> Assignee: Rafal Korytkowski
> Fix For: 10.x, Open To Community
>
>
> Requesting support for Exasol Connector
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 8 months