January 2018 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-5211) Allow ability to forward-engineer into underlying data stores

by Don Krapohl (JIRA)

[ https://issues.jboss.org/browse/TEIID-5211?page=com.atlassian.jira.plugin... ] Don Krapohl commented on TEIID-5211: ------------------------------------ Understood on the nature of the metadata repository. The architecture differences between the metadata and the source would I presume be encoded into the translators. > Allow ability to forward-engineer into underlying data stores > ------------------------------------------------------------- > > Key: TEIID-5211 > URL: https://issues.jboss.org/browse/TEIID-5211 > Project: Teiid > Issue Type: Enhancement > Components: Connector API > Reporter: Don Krapohl > Assignee: Steven Hawkins > > As a platform I am better able to better engineer my underlying data stores starting with a virtual model. > Please add the ability to create, alter, and drop schema objects and relationahips (DDL) in underlying data sources. Example, if I design a source in Teiid Designer I may wish to have Teiid do the DDL against the underlying data source(s). This allows better abstraction an portability of the data model. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5211) Allow ability to forward-engineer into underlying data stores

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-5211?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-5211: ------------------------------------- Why does connection change? Curious to learn how you are using with Streaming sources? Schema change in Teiid, either source or view model, does not make much difference the amount of work, I suspect handling source push down of the schema is more work as I was saying above. In either case, what Teiid lacking in that model is a repository for metadata and architecture differences with VDB artifact deployment model. Currently, metadata is refreshed at VDB deployment event, whereas with the other you need a central metadata repository where the VDB operates directly from and repository and can be dynamically updated. > Allow ability to forward-engineer into underlying data stores > ------------------------------------------------------------- > > Key: TEIID-5211 > URL: https://issues.jboss.org/browse/TEIID-5211 > Project: Teiid > Issue Type: Enhancement > Components: Connector API > Reporter: Don Krapohl > Assignee: Steven Hawkins > > As a platform I am better able to better engineer my underlying data stores starting with a virtual model. > Please add the ability to create, alter, and drop schema objects and relationahips (DDL) in underlying data sources. Example, if I design a source in Teiid Designer I may wish to have Teiid do the DDL against the underlying data source(s). This allows better abstraction an portability of the data model. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5211) Allow ability to forward-engineer into underlying data stores

by Don Krapohl (JIRA)

[ https://issues.jboss.org/browse/TEIID-5211?page=com.atlassian.jira.plugin... ] Don Krapohl commented on TEIID-5211: ------------------------------------ Completely reasonable. We do that now in fact. The idea was instead to change the source model connection and have it create all the schema objects in the underlying sources. That allows in-mem and streaming sources specifically to just begin loading the data without any scripting--just a connection change in the ETL/streaming tier. It makes for a more rapid migration in several scenarios. > Allow ability to forward-engineer into underlying data stores > ------------------------------------------------------------- > > Key: TEIID-5211 > URL: https://issues.jboss.org/browse/TEIID-5211 > Project: Teiid > Issue Type: Enhancement > Components: Connector API > Reporter: Don Krapohl > Assignee: Steven Hawkins > > As a platform I am better able to better engineer my underlying data stores starting with a virtual model. > Please add the ability to create, alter, and drop schema objects and relationahips (DDL) in underlying data sources. Example, if I design a source in Teiid Designer I may wish to have Teiid do the DDL against the underlying data source(s). This allows better abstraction an portability of the data model. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5211) Allow ability to forward-engineer into underlying data stores

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-5211?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-5211: ------------------------------------- In that case what is the issue if you were to update your source using whatever scripting or other methods and just reloading the Teiid VDB? > Allow ability to forward-engineer into underlying data stores > ------------------------------------------------------------- > > Key: TEIID-5211 > URL: https://issues.jboss.org/browse/TEIID-5211 > Project: Teiid > Issue Type: Enhancement > Components: Connector API > Reporter: Don Krapohl > Assignee: Steven Hawkins > > As a platform I am better able to better engineer my underlying data stores starting with a virtual model. > Please add the ability to create, alter, and drop schema objects and relationahips (DDL) in underlying data sources. Example, if I design a source in Teiid Designer I may wish to have Teiid do the DDL against the underlying data source(s). This allows better abstraction an portability of the data model. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5211) Allow ability to forward-engineer into underlying data stores

by Don Krapohl (JIRA)

[ https://issues.jboss.org/browse/TEIID-5211?page=com.atlassian.jira.plugin... ] Don Krapohl commented on TEIID-5211: ------------------------------------ We'd only need to forward engineer the source model. The view model wouldn't be required as it's an abstraction and doesn't need to be forward-engineered. Permission requirements can be managed through documentation. There are two scenarios--green field where none of the schema objects exist is the easiest, and also cases in which a version of the model already exists. I'd say a green field source model migration would be a great start. > Allow ability to forward-engineer into underlying data stores > ------------------------------------------------------------- > > Key: TEIID-5211 > URL: https://issues.jboss.org/browse/TEIID-5211 > Project: Teiid > Issue Type: Enhancement > Components: Connector API > Reporter: Don Krapohl > Assignee: Steven Hawkins > > As a platform I am better able to better engineer my underlying data stores starting with a virtual model. > Please add the ability to create, alter, and drop schema objects and relationahips (DDL) in underlying data sources. Example, if I design a source in Teiid Designer I may wish to have Teiid do the DDL against the underlying data source(s). This allows better abstraction an portability of the data model. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5211) Allow ability to forward-engineer into underlying data stores

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-5211?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-5211: ------------------------------------- Pushing the schema changes unto the source database maybe stretch as there can be various complications as you are saying including user-level permissions. Teiid first needs to get to a place where a view can be dynamically added/modified. > Allow ability to forward-engineer into underlying data stores > ------------------------------------------------------------- > > Key: TEIID-5211 > URL: https://issues.jboss.org/browse/TEIID-5211 > Project: Teiid > Issue Type: Enhancement > Components: Connector API > Reporter: Don Krapohl > Assignee: Steven Hawkins > > As a platform I am better able to better engineer my underlying data stores starting with a virtual model. > Please add the ability to create, alter, and drop schema objects and relationahips (DDL) in underlying data sources. Example, if I design a source in Teiid Designer I may wish to have Teiid do the DDL against the underlying data source(s). This allows better abstraction an portability of the data model. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5132) max-active-plans property limit one higher than set.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-5132?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-5132: ------------------------------------------------ Andrej Smigala <asmigala(a)redhat.com> changed the Status of [bug 1508348|https://bugzilla.redhat.com/show_bug.cgi?id=1508348] from ON_QA to VERIFIED > max-active-plans property limit one higher than set. > ---------------------------------------------------- > > Key: TEIID-5132 > URL: https://issues.jboss.org/browse/TEIID-5132 > Project: Teiid > Issue Type: Bug > Components: Server > Affects Versions: 8.12.x-6.4 > Reporter: Andrej Šmigala > Assignee: Steven Hawkins > Priority: Minor > Fix For: 8.12.x-6.4, 10.1 > > > Setting the max-active-plans property limits the number of queries that are processed concurrently, however, in our testing, the actual number of concurrent queries is consistently one higher than the max-active-plans setting, i.e. setting max-active-plans to 1 allows two concurrent queries etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5054) autoFailover with a multi-batch result timing issue

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5054?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5054: --------------------------------------- [~asmigala] Set autoFailover=true and issue a query that has multiple result batches. Fully read the results. You can also use the unit test https://github.com/teiid/teiid/blob/01b968a220e981ee820ab1b07df148833eb8b... without the fix it will hang. > autoFailover with a multi-batch result timing issue > --------------------------------------------------- > > Key: TEIID-5054 > URL: https://issues.jboss.org/browse/TEIID-5054 > Project: Teiid > Issue Type: Bug > Components: JDBC Driver > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Blocker > Fix For: 10.0, 8.12.x-6.4, 9.2.6, 9.3.3 > > > With autoFailover=true there is a periodic ping before usage of the connection. This ping may be called during processing of multi-batch results such that the ping call effectively hangs. 4 minutes later (or whatever the synch timeout is) the client will attempt to failover. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5236) Document and update GeoServer/PG JDBC compatibility

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5236?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5236. ----------------------------------- Fix Version/s: 10.1.1 Resolution: Done Updated the logic to support all of the pg driver usage from geoserver 2.8 and 2.12. There are some constructs that we still don't support, such as the pg table valued functions that we instead just fully override the queries. We'll continue to revisit this as necessary. > Document and update GeoServer/PG JDBC compatibility > --------------------------------------------------- > > Key: TEIID-5236 > URL: https://issues.jboss.org/browse/TEIID-5236 > Project: Teiid > Issue Type: Quality Risk > Components: Documentation, ODBC, Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 10.1.1, 10.2 > > > It is not documented on the geoserver integration page, but most of the initial work was done against versions between 2.6 and 2.8. It appears that even 2.8 can have issues as it can use the 9.4 postgresql driver, which expects additional syntax support for type metadata. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5165) Infinispan hotrod translator fails with growing size of returned data

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-5165?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-5165: ------------------------------------------------ Jan Stastny <jstastny(a)redhat.com> changed the Status of [bug 1515197|https://bugzilla.redhat.com/show_bug.cgi?id=1515197] from ON_QA to VERIFIED > Infinispan hotrod translator fails with growing size of returned data > --------------------------------------------------------------------- > > Key: TEIID-5165 > URL: https://issues.jboss.org/browse/TEIID-5165 > Project: Teiid > Issue Type: Bug > Components: JDG Connector, Misc. Connectors > Affects Versions: 8.12.x-6.4 > Reporter: Jan Stastny > Assignee: Van Halbert > Priority: Blocker > Fix For: 8.12.x-6.4, 10.x > > > Infinispan Hotrod translator fails depending on size of data returned. > I have a table with more than 5000 rows. > When I issue following query: > {code:sql} > SELECT IntKey FROM BQT1.LargeA WHERE Intkey<4095 > {code} > correct results are returned. > | 0 | > | 1 | > | ... | > | 4094 | > When I issue: > {code:sql} > SELECT IntKey FROM BQT1.LargeA WHERE Intkey<4096 > {code} > following exception occurs and no results are returned: > {code} > 12:27:56,933 ERROR [org.teiid.CONNECTOR] (Worker8_QueryProcessorQueue279) Connector worker process failed for atomic-request=+VUUR2vieWhT.59.0.46: java.util.NoSuchElementException > at java.util.ArrayList$Itr.next(ArrayList.java:860) [rt.jar:1.8.0_151] > at org.teiid.translator.infinispan.hotrod.InfinispanResponse.getNextRow(InfinispanResponse.java:106) [translator-infinispan-hotrod-8.12.11.6_4-redhat-7.jar:8.12.11.6_4-redhat-7] > at org.teiid.translator.infinispan.hotrod.InfinispanQueryExecution.next(InfinispanQueryExecution.java:142) [translator-infinispan-hotrod-8.12.11.6_4-redhat-7.jar:8.12.11.6_4-redhat-7] > at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.handleBatch(ConnectorWorkItem.java:433) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7] > at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.more(ConnectorWorkItem.java:236) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7] > 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) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7] > at com.sun.proxy.$Proxy79.more(Unknown Source) > at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:309) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7] > at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:112) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7] > at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7] > 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) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7] > at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:284) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7] > at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7] > at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.12.11.6_4-redhat-64-7.jar:8.12.11.6_4-redhat-64-7] > 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] > 12:27:56,941 WARN [org.teiid.PROCESSOR] (Worker7_QueryProcessorQueue282) TEIID30020 Processing exception for request +VUUR2vieWhT.59 'TEIID30504 jdg7-source: null'. Originally TeiidProcessingException ArrayList.java:860. Enable more detailed logging to see the entire stacktrace. > {code} > Please note, that this is not affected only by number of rows, also by number of columns. So we're hitting a size limit on whole result set (influence of data type size has not been confirmed). > This affects also DELETE operation, as selection is part of the operation. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues January 2018