[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
[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
[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
[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
[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
[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
[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
[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