[JBoss JIRA] (TEIID-3957) Impala translator - Add pushdown of offset in LIMIT clause to overcome difference in LIMIT clause
by Don Krapohl (JIRA)
Don Krapohl created TEIID-3957:
----------------------------------
Summary: Impala translator - Add pushdown of offset in LIMIT clause to overcome difference in LIMIT clause
Key: TEIID-3957
URL: https://issues.jboss.org/browse/TEIID-3957
Project: Teiid
Issue Type: Bug
Components: JDBC Connector
Affects Versions: 8.12.4
Environment: Ubuntu Trusty
Reporter: Don Krapohl
Assignee: Steven Hawkins
Priority: Minor
With the impala translator we issue this LIMIT to Teiid:
ORDER BY somecolumn DESC LIMIT 75, 25
this means give me 25 rows starting from *ROW* 76.
In Impala's SQL this should be translated to:
ORDER BY somecolumn DESC LIMIT 25 OFFSET 75
BUT this means give me 25 rows starting from *PAGE * 76 (with page size of 25 rows)
ref: http://www.cloudera.com/documentation/archive/impala/2-x/2-1-x/topics/imp...
The Teiid Impala translator doesn't push the offset but sums the limit and offset:
ORDER BY somecolumn DESC LIMIT 100
Request we add pushdown, which will be more efficient and overcome the difference in how offsets are handled between Impala and Teiid.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (TEIID-3351) Quick Start "dynamicvdb-datafederation" needlessly made complicated
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3351?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-3351:
------------------------------------
I'll create another quick start that imports the Portfolio vdb and includes the excel data source.
> Quick Start "dynamicvdb-datafederation" needlessly made complicated
> -------------------------------------------------------------------
>
> Key: TEIID-3351
> URL: https://issues.jboss.org/browse/TEIID-3351
> Project: Teiid
> Issue Type: Quality Risk
> Components: Quick Starts
> Reporter: Ramesh Reddy
> Assignee: Van Halbert
> Fix For: 8.12.x
>
>
> The "dynamicvdb-datafederation" example in the Quick Starts example is needlessly made complicated. Originally this is designed to have one File and RDBMS source, to show a simple data integration through Teiid.
> Now, it has
> - Excel integration
> - Materialization Example
> - more models
> I am not opposed to having these features shown in an example, however not in this example. This needs to be as simple as possible to show a quick introduction to the Teiid. Please move these into separate quick starts.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (TEIID-3351) Quick Start "dynamicvdb-datafederation" needlessly made complicated
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-3351?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-3351:
------------------------------------
that's subjective. It still has the excel data source.
> Quick Start "dynamicvdb-datafederation" needlessly made complicated
> -------------------------------------------------------------------
>
> Key: TEIID-3351
> URL: https://issues.jboss.org/browse/TEIID-3351
> Project: Teiid
> Issue Type: Quality Risk
> Components: Quick Starts
> Reporter: Ramesh Reddy
> Assignee: Van Halbert
> Fix For: 8.12.x
>
>
> The "dynamicvdb-datafederation" example in the Quick Starts example is needlessly made complicated. Originally this is designed to have one File and RDBMS source, to show a simple data integration through Teiid.
> Now, it has
> - Excel integration
> - Materialization Example
> - more models
> I am not opposed to having these features shown in an example, however not in this example. This needs to be as simple as possible to show a quick introduction to the Teiid. Please move these into separate quick starts.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (TEIID-2132) Teiid 8.0 API does not expose boundport in Mbean attribute for Teiid-JDBC
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2132?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2132:
----------------------------------
Fix Version/s: 9.0
I'll bucket this to 9.0, and then we can determine from there if it's worth pursuing.
> Teiid 8.0 API does not expose boundport in Mbean attribute for Teiid-JDBC
> -------------------------------------------------------------------------
>
> Key: TEIID-2132
> URL: https://issues.jboss.org/browse/TEIID-2132
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.0
> Environment: jboss 7, teiid 8, windows 7
> Reporter: Akshay Harale
> Assignee: Ramesh Reddy
> Priority: Minor
> Labels: jboss, teiid
> Fix For: 9.0
>
>
> When offset is set for jboss from standalone.xml or standalone.conf.bat file, the bound port is not displyed in MBean server.
>
> For example,
>
> <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:25}">
>
> In above line if I set the value as 25 then that should be added to the default socket port values and exposed as bound port value in MBean server. But in case of teiid the "teiid-jdbc" 's boundPort value is not exposed by the jboss.
>
> All other boundPorts values are correctly shown in Mbean, except teiid-jdbc
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (TEIID-3351) Quick Start "dynamicvdb-datafederation" needlessly made complicated
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3351?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3351:
---------------------------------------
So dynamicvdb-datafederation will then just be stripped to a simple example after that?
> Quick Start "dynamicvdb-datafederation" needlessly made complicated
> -------------------------------------------------------------------
>
> Key: TEIID-3351
> URL: https://issues.jboss.org/browse/TEIID-3351
> Project: Teiid
> Issue Type: Quality Risk
> Components: Quick Starts
> Reporter: Ramesh Reddy
> Assignee: Van Halbert
> Fix For: 8.12.x
>
>
> The "dynamicvdb-datafederation" example in the Quick Starts example is needlessly made complicated. Originally this is designed to have one File and RDBMS source, to show a simple data integration through Teiid.
> Now, it has
> - Excel integration
> - Materialization Example
> - more models
> I am not opposed to having these features shown in an example, however not in this example. This needs to be as simple as possible to show a quick introduction to the Teiid. Please move these into separate quick starts.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (TEIID-3952) Update to updatable internal materialized view should update the materialized view as well as the database
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3952?page=com.atlassian.jira.plugin... ]
Steven Hawkins reassigned TEIID-3952:
-------------------------------------
Fix Version/s: 9.0
Assignee: Steven Hawkins (was: Barry LaFond)
> Update to updatable internal materialized view should update the materialized view as well as the database
> ----------------------------------------------------------------------------------------------------------
>
> Key: TEIID-3952
> URL: https://issues.jboss.org/browse/TEIID-3952
> Project: Teiid
> Issue Type: Enhancement
> Components: VDB
> Affects Versions: 8.7
> Environment: Red Hat JBoss Data Virtualization 6.2 based on Teiid 8.7.x
> Reporter: Andy Yuen
> Assignee: Steven Hawkins
> Labels: jboss
> Fix For: 9.0
>
>
> Updating an updatable internal materized view updates the database but not the materialized view at present. The requested enhancement is that they, both, should be updated.
> Setup
> Client - SquirrelSQL to access JDV
> JDV 6.2 - with an updatable nternal materialized view of one table from the data source
> Data Source - just one data source: MySQL
> I can see from the console that the target table/view has been materialized
> Then I did the following:
> 1) select a row from the materialized table
> 2) update a field in a row in the materialized view
> 3) select that row (value unchanged ie, same as int 1) - tried multiple times
> 4) issue EXEC SYSADMIN.refreshMatViewRow(...) using primary key for the row that has been changed
> 5) select that row (value unchanged) - now I can see the changed data
> This behaviour is counter-intuitive because I was expecting that since it is an updatable materialized view, my change will write through the materialized view ie, change both the materialized view as well as the database. But in this case, it changed the database and not the materialized view?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (TEIID-3953) .TeiidRuntimeException: TEIID20001 The modeled datatype string for column 1 doesn't match the runtime type "java.math.BigDecimal".
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3953?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3953:
---------------------------------------
Let's connect through our jboss.org accounts.
> .TeiidRuntimeException: TEIID20001 The modeled datatype string for column 1 doesn't match the runtime type "java.math.BigDecimal".
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-3953
> URL: https://issues.jboss.org/browse/TEIID-3953
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.11.4
> Environment: Windows server 2012 R2
> Reporter: Lukas Mro
> Assignee: Steven Hawkins
>
> 13:18:51,809 INFO [org.teiid.CONNECTOR] (Worker19_QueryProcessorQueue264) EWgzC7sVHcNy SimpleJDBCExecutionFactory Commit=true;DatabaseProductName=Firebird 2.5.WI;DatabaseProductVersion=WI-V2.5.3.26780;DriverMajorVersion=2;DriverMajorVersion=2;DriverName=Jaybird JCA/JDBC driver;DriverVersion=2.2;IsolationLevel=2
> 13:18:51,855 ERROR [org.teiid.TRANSPORT] (New I/O worker #4) null TEIID40113 Unhandled exception, aborting operation: org.teiid.transport.ObjectEncoder$FailedWriteException: org.teiid.core.TeiidRuntimeException: TEIID20001 The modeled datatype string for column 1 doesn't match the runtime type "java.math.BigDecimal". Please ensure that the column's modeled datatype matches the expected data.
> at org.teiid.transport.ObjectEncoder.handleDownstream(ObjectEncoder.java:136) [teiid-runtime-8.11.4.jar:8.11.4]
> at org.jboss.netty.channel.Channels.write(Channels.java:704) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.Channels.write(Channels.java:671) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:248) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1]
> at org.teiid.transport.SSLAwareChannelHandler$ObjectChannelImpl.write(SSLAwareChannelHandler.java:93) [teiid-runtime-8.11.4.jar:8.11.4]
> at org.teiid.transport.SocketClientInstance.send(SocketClientInstance.java:88) [teiid-runtime-8.11.4.jar:8.11.4]
> at org.teiid.transport.ServerWorkItem.sendResult(ServerWorkItem.java:135) [teiid-runtime-8.11.4.jar:8.11.4]
> at org.teiid.transport.ServerWorkItem$1.onCompletion(ServerWorkItem.java:105) [teiid-runtime-8.11.4.jar:8.11.4]
> at org.teiid.client.util.ResultsFuture.done(ResultsFuture.java:135) [teiid-client-8.11.4.jar:8.11.4]
> at org.teiid.client.util.ResultsFuture.access$200(ResultsFuture.java:40) [teiid-client-8.11.4.jar:8.11.4]
> at org.teiid.client.util.ResultsFuture$1.receiveResults(ResultsFuture.java:79) [teiid-client-8.11.4.jar:8.11.4]
> at org.teiid.dqp.internal.process.RequestWorkItem.sendResultsIfNeeded(RequestWorkItem.java:980) [teiid-engine-8.11.4.jar:8.11.4]
> at org.teiid.dqp.internal.process.RequestWorkItem$1.flushBatchDirect(RequestWorkItem.java:662) [teiid-engine-8.11.4.jar:8.11.4]
> at org.teiid.query.processor.BatchCollector.flushBatch(BatchCollector.java:223) [teiid-engine-8.11.4.jar:8.11.4]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:194) [teiid-engine-8.11.4.jar:8.11.4]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146) [teiid-engine-8.11.4.jar:8.11.4]
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:457) [teiid-engine-8.11.4.jar:8.11.4]
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:339) [teiid-engine-8.11.4.jar:8.11.4]
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) [teiid-engine-8.11.4.jar:8.11.4]
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:267) [teiid-engine-8.11.4.jar:8.11.4]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276) [teiid-engine-8.11.4.jar:8.11.4]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.11.4.jar:8.11.4]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.11.4.jar:8.11.4]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_75]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_75]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_75]
> Caused by: org.teiid.core.TeiidRuntimeException: TEIID20001 The modeled datatype string for column 1 doesn't match the runtime type "java.math.BigDecimal". Please ensure that the column's modeled datatype matches the expected data.
> at org.teiid.client.BatchSerializer.writeBatch(BatchSerializer.java:878) [teiid-client-8.11.4.jar:8.11.4]
> at org.teiid.client.ResultsMessage.writeExternal(ResultsMessage.java:319) [teiid-client-8.11.4.jar:8.11.4]
> at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1458) [rt.jar:1.7.0_75]
> at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1429) [rt.jar:1.7.0_75]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1177) [rt.jar:1.7.0_75]
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347) [rt.jar:1.7.0_75]
> at org.teiid.net.socket.Message.writeExternal(Message.java:61) [teiid-client-8.11.4.jar:8.11.4]
> at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1458) [rt.jar:1.7.0_75]
> at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1429) [rt.jar:1.7.0_75]
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1177) [rt.jar:1.7.0_75]
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347) [rt.jar:1.7.0_75]
> at org.teiid.transport.ObjectEncoder.handleDownstream(ObjectEncoder.java:131) [teiid-runtime-8.11.4.jar:8.11.4]
> ... 25 more
> Caused by: java.lang.ClassCastException: java.math.BigDecimal cannot be cast to java.lang.String
> at org.teiid.client.BatchSerializer$StringColumnSerializer3.writeObject(BatchSerializer.java:348) [teiid-client-8.11.4.jar:8.11.4]
> at org.teiid.client.BatchSerializer$ColumnSerializer.writeColumn(BatchSerializer.java:534) [teiid-client-8.11.4.jar:8.11.4]
> at org.teiid.client.BatchSerializer.writeBatch(BatchSerializer.java:867) [teiid-client-8.11.4.jar:8.11.4]
> ... 36 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (TEIID-3956) Retrieving just a stream property fails for OData4
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-3956:
-------------------------------------
Summary: Retrieving just a stream property fails for OData4
Key: TEIID-3956
URL: https://issues.jboss.org/browse/TEIID-3956
Project: Teiid
Issue Type: Bug
Components: OData
Affects Versions: 8.12
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 9.0
A property query, such as table/lobColumn will fail as under the covers an NPE occurs in the property handling logic.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (TEIID-3955) When the JDBC MetadataProcessor is reverse engineering, don't fail the VDB when there are warning on the metadata load
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3955?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3955:
---------------------------------------
Note that by logging something as a WARNING doesn't mean that it's not a problem, it just means that the system will continue to operate as normal and that it is an expected failure condition. Just like when someone issues a failing SQL query.
At most you would want to offer an option to ignore errors - but the logic would need tweaking as to how to recover (removing invalid tables, etc.)
> When the JDBC MetadataProcessor is reverse engineering, don't fail the VDB when there are warning on the metadata load
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-3955
> URL: https://issues.jboss.org/browse/TEIID-3955
> Project: Teiid
> Issue Type: Enhancement
> Components: JDBC Connector
> Reporter: Van Halbert
> Assignee: Steven Hawkins
> Priority: Minor
>
> When the JDBC metadata processor is reverse engineering the metadata and there are WARNINGS that it could not create the metadata for parts (not all) of the tables, then allow the VDB to be active, instead of failing it and making it inactive. Let the developer decide if what was not loaded requires further tuning of the import properties. Otherwise, the VDB may have what it needs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (TEIID-3955) When the JDBC MetadataProcessor is reverse engineering, don't fail the VDB when there are warning on the metadata load
by Van Halbert (JIRA)
Van Halbert created TEIID-3955:
----------------------------------
Summary: When the JDBC MetadataProcessor is reverse engineering, don't fail the VDB when there are warning on the metadata load
Key: TEIID-3955
URL: https://issues.jboss.org/browse/TEIID-3955
Project: Teiid
Issue Type: Enhancement
Components: JDBC Connector
Reporter: Van Halbert
Assignee: Steven Hawkins
Priority: Minor
When the JDBC metadata processor is reverse engineering the metadata and there are WARNINGS that it could not create the metadata for parts (not all) of the tables, then allow the VDB to be active, instead of failing it and making it inactive. Let the developer decide if what was not loaded requires further tuning of the import properties. Otherwise, the VDB may have what it needs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months