June 2018 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-5396) Querying SQL Server variant type for a string fails

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5396?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5396. ----------------------------------- Fix Version/s: 10.3.2 10.2.3 Resolution: Done To preserve the old behavior a change was needed to the ConvertModifier. However this also means that putting unicode strings in the column will return just ascii data. A workaround is to change the native type from sql_variant to nvarchar. Otherwise a code fix would be needed to add sql_variant as type that is possibly unicode. > Querying SQL Server variant type for a string fails > --------------------------------------------------- > > Key: TEIID-5396 > URL: https://issues.jboss.org/browse/TEIID-5396 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 8.12.14.6_4 > Reporter: Andrej Šmigala > Assignee: Steven Hawkins > Fix For: 11.0, 10.3.2, 10.2.3 > > > Table on SQL Server source created as > {code:sql}CREATE TABLE table_with_variant(id INT, var SQL_VARIANT){code} > and loaded with int, float and string data. > Running the following query against a dynamic VDB with metadata import > {code:sql}SELECT cast(var AS string) FROM table_with_variant WHERE id = 1{code} > fails with > {noformat}java.sql.SQLException: Remote com.microsoft.sqlserver.jdbc.SQLServerException: The "variant" data type is not supported.{noformat} > This query used to work with DV 6.4.2, it appears it is a further regression from TEIID-5313 . Querying rows with non-string data works as expected. > SOURCE SRC command with 6.4.2 (working): > {code:sql}SELECT cast(g_0."var" AS varchar(4000)) FROM "dballo05"."dbo"."table_with_variant" g_0 WHERE g_0."id" = 1{code} > SOURCE SRC command with 6.4.3 (not working), note missing cast to varchar: > {code:sql}SELECT g_0."var" FROM "dballo06"."dbo"."table_with_variant" g_0 WHERE g_0."id" = 1{code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 10 months

1
0
0 / 0

[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: ------------------------------------- Yes, that is an interesting and much better idea, treat like code. +1 > 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 > > 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)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5394) Define how to utilize multiple vdbs

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5394?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5394: --------------------------------------- > An idea here is to include the importing vdbs into same folder structure? We should probably think of this from a holistic perspective. There are two cases here - the general multi-vdb, and vdb import. The vdb import case has development time ramifications as well. If every usage of an imported vdb is effectively an independently maintained copy, then the feature won't have much meaning. Perhaps now that we support semantic versions we should think about imports being pulled from maven vdb artifacts? > 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 > > 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)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5398) Sybase translator error caused by change in ASCII function pushdown

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-5398?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-5398: --------------------------------- Fix Version/s: 8.12.14.6_4 > Sybase translator error caused by change in ASCII function pushdown > ------------------------------------------------------------------- > > Key: TEIID-5398 > URL: https://issues.jboss.org/browse/TEIID-5398 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.12.14.6_4 > Reporter: Jan Stastny > Assignee: Steven Hawkins > Priority: Critical > Fix For: 11.0, 10.3.2, 10.2.3, 8.12.14.6_4 > > > There's a regression caused by TEIID-5313 change: > {code:java} > registerFunctionModifier(SourceSystemFunctions.ASCII, new AliasModifier("unicode")); //$NON-NLS-1$ > {code} > Following query: > {code:sql} > SELECT INTKEY, ASCII(INTKEY) FROM BQT1.SmallA > {code} > being resolved to following src command: > {code:sql} > SELECT g_0.intkey, unicode(cast(g_0.intkey AS varchar(4000))) FROM smalla g_0 > {code} > results in following error: > {code:title=server.log} > 12:42:04,102 WARN [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue18) Connector worker process failed for atomic-request=reZs6o4Ybhhc.8.0.1: org.teiid.translator.jdbc.JDBCExecutionException: 14216 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: [] SQL: SELECT g_0.intkey, unicode(cast(g_0.intkey AS varchar(4000))) FROM smalla g_0] > at org.teiid.translator.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:131) [translator-jdbc-8.12.14.6_4-redhat-64-2.jar:8.12.14.6_4-redhat-64-2] > at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:361) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_151] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar: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: com.sybase.jdbc4.jdbc.SybSQLException: Function 'unicode' not found. If this is a SQLJ function or SQL function, use sp_help to check whether the object exists (sp_help may produce a large amount of output). > at com.sybase.jdbc4.tds.Tds.processEed(Tds.java:4003) > at com.sybase.jdbc4.tds.Tds.nextResult(Tds.java:3093) > at com.sybase.jdbc4.jdbc.ResultGetter.nextResult(ResultGetter.java:78) > at com.sybase.jdbc4.jdbc.SybStatement.nextResult(SybStatement.java:289) > at com.sybase.jdbc4.jdbc.SybStatement.nextResult(SybStatement.java:271) > at com.sybase.jdbc4.jdbc.SybStatement.queryLoop(SybStatement.java:2408) > at com.sybase.jdbc4.jdbc.SybStatement.executeQuery(SybStatement.java:2394) > at com.sybase.jdbc4.jdbc.SybPreparedStatement.executeQuery(SybPreparedStatement.java:257) > 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.14.6_4-redhat-64-2.jar:8.12.14.6_4-redhat-64-2] > ... 18 more > 12:42:04,118 WARN [org.teiid.PROCESSOR] (Worker0_QueryProcessorQueue19) TEIID30020 Processing exception for request reZs6o4Ybhhc.8 'TEIID30504 Source: 14216 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: [] SQL: SELECT g_0.intkey, unicode(cast(g_0.intkey AS varchar(4000))) FROM smalla g_0]'. Originally TeiidProcessingException 'Function 'unicode' not found. If this is a SQLJ function or SQL function, use sp_help to check whether the object exists (sp_help may produce a large amount of output). > ' Tds.java:4003. Enable more detailed logging to see the entire stacktrace. > {code} > SRC Command in previous version: > {code:sql} > SELECT g_0.intkey, ascii(cast(g_0.intkey AS varchar(4000))) FROM smalla g_0 > {code} > NOTE: the issue is not caused by casting int to varchar, happens also when calling ASCII function on string directly. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 10 months

1
0
0 / 0

[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 edited comment on TEIID-5394 at 6/27/18 11:33 AM: --------------------------------------------------------------- An idea here is to include the importing vdbs into same folder structure? I am not sure how much nesting of importing vdbs Teiid supports, but something like should work. {code} /src/main/vdb portfolio-vdb.xml import/ abc/ abc-vdb.xml xyz/ xyz-vdb.xml {code} There will be intervening directories to support TEIID-5392. The big question is either we can undo the nesting during the deployment time and deploy multiple vdbs Vs redefine the VDB structure such that we change the deployer in Teiid. was (Author: rareddy): An idea here is to include the importing vdbs into same folder structure? I am not sure how much nesting of importing vdbs Teiid supports, but something like should work. {code} /src/main/vdb portfolio-vdb.xml import/ abc/ abc-vdb.xml xyz/ xyz-vdb.xml {code} There will be intervening directories to support TEIID-5392 > 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 > > 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)

5 years, 10 months

1
0
0 / 0

[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: ------------------------------------- An idea here is to include the importing vdbs into same folder structure? I am not sure how much nesting of importing vdbs Teiid supports, but something like should work. {code} /src/main/vdb portfolio-vdb.xml import/ abc/ abc-vdb.xml xyz/ xyz-vdb.xml {code} There will be intervening directories to support TEIID-5392 > 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 > > 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)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5395) Improvement of JPA translator join behavior

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-5395?page=com.atlassian.jira.plugin... ] Ramesh Reddy updated TEIID-5395: -------------------------------- Fix Version/s: 11.0 > Improvement of JPA translator join behavior > ------------------------------------------- > > Key: TEIID-5395 > URL: https://issues.jboss.org/browse/TEIID-5395 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Affects Versions: 10.2.1 > Reporter: Harold Campbell > Assignee: Steven Hawkins > Priority: Minor > Fix For: 11.0 > > > The behavior of the JPA connector has a number of issues regarding entity relationships. > * Implicit joins (those needed to get child entity id's) are made INNER JOINS, preventing getting any rows where the value would be null. > * Something odd is done with *ToMany relationships which blows up the size of resultsets. > * If a parent entity and a child entity use the same name for their id property, only one gets mapped. > * It's not possible to join the same entity more than once. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5395) Improvement of JPA translator join behavior

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-5395?page=com.atlassian.jira.plugin... ] Ramesh Reddy resolved TEIID-5395. --------------------------------- Resolution: Done > Improvement of JPA translator join behavior > ------------------------------------------- > > Key: TEIID-5395 > URL: https://issues.jboss.org/browse/TEIID-5395 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Affects Versions: 10.2.1 > Reporter: Harold Campbell > Assignee: Steven Hawkins > Priority: Minor > Fix For: 11.0 > > > The behavior of the JPA connector has a number of issues regarding entity relationships. > * Implicit joins (those needed to get child entity id's) are made INNER JOINS, preventing getting any rows where the value would be null. > * Something odd is done with *ToMany relationships which blows up the size of resultsets. > * If a parent entity and a child entity use the same name for their id property, only one gets mapped. > * It's not possible to join the same entity more than once. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5399) JPA translator: Add support for pagination

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-5399?page=com.atlassian.jira.plugin... ] Ramesh Reddy resolved TEIID-5399. --------------------------------- Resolution: Done Labels: Final (was: ) Thank you [~traivor] > JPA translator: Add support for pagination > ------------------------------------------ > > Key: TEIID-5399 > URL: https://issues.jboss.org/browse/TEIID-5399 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Reporter: Harold Campbell > Assignee: Steven Hawkins > Priority: Minor > Labels: Final > Fix For: 11.0 > > > The JPA connector doesn't currently support rowOffset & rowLimit, making pagination of large datasets memory hungry. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5399) JPA translator: Add support for pagination

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-5399?page=com.atlassian.jira.plugin... ] Ramesh Reddy updated TEIID-5399: -------------------------------- Fix Version/s: 11.0 > JPA translator: Add support for pagination > ------------------------------------------ > > Key: TEIID-5399 > URL: https://issues.jboss.org/browse/TEIID-5399 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Reporter: Harold Campbell > Assignee: Steven Hawkins > Priority: Minor > Fix For: 11.0 > > > The JPA connector doesn't currently support rowOffset & rowLimit, making pagination of large datasets memory hungry. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues June 2018