June 2011 - teiid-issues - Jboss List Archives

[JBoss JIRA] Created: (TEIID-1645) SELECT COUNT(*) FROM VQT.Agg3 is expecting a result of 1 but 50 is being returned

by Warren Gibson (JIRA)

SELECT COUNT(*) FROM VQT.Agg3 is expecting a result of 1 but 50 is being returned --------------------------------------------------------------------------------- Key: TEIID-1645 URL: https://issues.jboss.org/browse/TEIID-1645 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 7.5 Reporter: Warren Gibson Assignee: Steven Hawkins Attachments: QT_MySql50_Push.vdb The VQT.Agg3 transformation is: SELECT COUNT(*)FROM BQT1.SmallA. BQT is expecting 1 to be returned but is getting 50. VDB attached. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

3
7
0 / 0

[JBoss JIRA] Created: (TEIID-1621) Unexpected grouping for SELECT queries on views that include a GROUP BY

by Claudio Venturini (JIRA)

Unexpected grouping for SELECT queries on views that include a GROUP BY ----------------------------------------------------------------------- Key: TEIID-1621 URL: https://issues.jboss.org/browse/TEIID-1621 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 7.4 Environment: Teiid 7.4 (with patch) deployed on JBoss AS 5.1, installed on Ubuntu Server 10.04 LTS. Four source models, two of which in MySQL 5.1.51 (on the same machine of JBoss), one on SQLServer 2000 (on another machine), and one on SQL Server 2005 (on another machine). All sources participate in XA transactions. Reporter: Claudio Venturini Assignee: Steven Hawkins Attachments: server.log I've a set of models like the one that I've already explained in https://issues.jboss.org/browse/TEIID-1562. In addition I've a physical model, named sole_rugiada_phy, which extracts data from a SQL Server 2005 database. On top of it there's a view model, named sole_rugiada_log, which transform some fields and does some joins grouping. In particular the base table named 'vendita_referenza' is defined as follows: {code:sql} SELECT SR_op.codop, CAST(SR_v.n_bolla AS VARCHAR) AS codice, SUP_ro.codref, SR_v.data, CAST(SR_v.n_prog AS INTEGER) AS n_prog, CAST(SUM(SR_v.quantita) AS INTEGER) AS quantita, SUM((((SUP_r.quantita / SUP_ro.quantita_reale) * SR_v.quantita) * SR_v.prezzo)) AS fatturato, COUNT(*) AS groupdim FROM ((sole_rugiada_phy.MISURA124.dbo.VENDITA_REFERENZA AS SR_v INNER JOIN support_log.mediator.referenza_op AS SUP_ro ON RTRIM(LTRIM(CAST(SR_v.codref AS VARCHAR))) = SUP_ro.codice) INNER JOIN support_log.mediator.referenza AS SUP_r ON SUP_ro.codref = SUP_r.codref) INNER JOIN sole_rugiada_log.misura124.solerugiada.op AS SR_op ON SUP_ro.codop = SR_op.codop WHERE SR_v.data >= PARSEDATE('20090701', 'yyyyMMdd') GROUP BY SR_op.codop, SR_v.data, SR_v.n_bolla, SR_v.n_prog, SUP_ro.codref {code} If I run the following query, that is a simple SELECT statement, everything works fine: {code:sql} SELECT codop, codice, codref, data, n_prog, quantita, fatturato, groupdim FROM sole_rugiada_log.misura124.solerugiada.vendita_referenza {code} The query above retrieves 18717 records. But if I remove some fields from the SELECT statements something goes wrong. Take for example the following query: {code:sql} SELECT codop, codref, data, quantita, fatturato FROM sole_rugiada_log.misura124.solerugiada.vendita_referenza {code} The above query gets only one record, which is a grouping over all the record, even if it doesn't include a GROUP BY clause. It's not clear what type of aggregation it does. It seems to be a sum of all records, but the result is not totally exact. The value of 'fatturato' is near the real sum (5043502.561000000 instead of 5046687.249000000), but the value of 'quantita' is much different from the real sum (489566 instead of 5537638). I noticed that removing the GROUP BY from the definition of the base table the problem disappears, but, of course, most of times this cannot be used as a workaround. Attached there are the project of the VDB and a log of the execution of the query that produces the wrong result. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

3
4
0 / 0

[JBoss JIRA] Created: (TEIID-1653) Support Cursoring over ODBC protocol ( support UseDeclareFetch = 1)

by Ramesh Reddy (JIRA)

Support Cursoring over ODBC protocol ( support UseDeclareFetch = 1) ------------------------------------------------------------------- Key: TEIID-1653 URL: https://issues.jboss.org/browse/TEIID-1653 Project: Teiid Issue Type: Feature Request Components: ODBC Affects Versions: 7.1.1 Reporter: Ramesh Reddy Assignee: Ramesh Reddy Fix For: 7.4.1, 7.5, 7.1.1 Postgres ODBC driver, retrieves all the rows from server for "select" request before it passes a single row to the calling client. This requires additional memory overhead for the client applications that dealing with very large resultset, which can lead to OOM issues. Postgres ODBC driver supports a couple properties UseDeclareFetch = 1 Fetch=1000 using which, ODBC driver will form the queries using postgres "cursor" functionality, and only fetch number of rows that are defined with variable "Fetch". This will result in faster initial response time to the user (especially UI based apps) because the driver is not fetching all rows, it is only fetching the first batch. Also, minimal memory foot print as it can clear the results as they are delivered to the client application, especially with FORWARD only cursor. Teiid will only support for FORWARD ONLY cursor. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (TEIID-1563) Refresh a Materialized View without parameters from admin console

by Stephen Brooks (JIRA)

Refresh a Materialized View without parameters from admin console ----------------------------------------------------------------- Key: TEIID-1563 URL: https://issues.jboss.org/browse/TEIID-1563 Project: Teiid Issue Type: Bug Components: Server Affects Versions: 7.1.1 Environment: EDS on RHEL 5, Admin Console with Firefox 4.0 Reporter: Stephen Brooks Assignee: Steven Hawkins Priority: Minor Found an EDS bug in the admin console where it tries to refresh without parameters. Steps to reproduce: 1. Go to the 'Control' tab for a VDB 2. Click 'Refresh a Materialized View' 3. Don't enter information, just click 'Cancel' 4. Click 'Refresh a Materialized View' again -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

5
6
0 / 0

[JBoss JIRA] Created: (TEIID-1596) Document queryThresholdInSecs and allow functionality to ensure user queries take no longer than a specified interval

by Graeme Gillies (JIRA)

Document queryThresholdInSecs and allow functionality to ensure user queries take no longer than a specified interval --------------------------------------------------------------------------------------------------------------------- Key: TEIID-1596 URL: https://issues.jboss.org/browse/TEIID-1596 Project: Teiid Issue Type: Feature Request Reporter: Graeme Gillies Assignee: Steven Hawkins In the teiid documentation there is no mention (from what I can find) of exactly what the option queryThresholdInSecs does. The xml file states "Long running query threshold, after which a alert can be generated by tooling if configured", what tooling is this exactly? Does it alert and stop the query, or just alert? On the same token, there is the configuration item maxSourceRows which is configured per instance. Unfortunately this isn't flexible enough sometimes, and it would be better if this option could be configured per VDB and per data role as well (some people can get more data than others). I would expect the determination of what maxSourceRows is for a query should be as follows 1) If maxSourceRows is set for the data role the user has, use that (in the case of two data roles with different values, use the largest value) 2) If maxSourceRows is not set on any of the users data role, but set on the vdb, use that value 3) If maxSourceRows is not set on the vdb or any data roles the user has, use the instance setting. Likewise, the setting maxSourceRows should not only be configurable per data role, vdb, instance, but also the setting queryThresholdInSecs, and either that option or another option should be put in place that allows us to hard limit the length of time a query can run. This is because in teiid we want to be able to say users cannot write a big huge query that will take more than X amount of seconds to execute, to stop someone in teiid giving it a huge query and hammering all the backend databases. Configuring this option by vdb and data role (as some people are more trusted and can run longer queries) would be fantastic. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

3
9
0 / 0

[JBoss JIRA] Created: (TEIID-554) searchability metadata should be type based

by Steven Hawkins (JIRA)

searchability metadata should be type based ------------------------------------------- Key: TEIID-554 URL: https://jira.jboss.org/jira/browse/TEIID-554 Project: Teiid Issue Type: Quality Risk Components: Query Engine Affects Versions: 6.0.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Priority: Minor Fix For: 6.x Since searchability metadata is element based our check for (CapabilitiesUtil) gathers all elements in the expression - regardless of the type of the whole expression. This may be quite difficult to make this change in the existing metadata framework. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (TEIID-1070) Create Amazon SimpleDB Connector

by John Doyle (JIRA)

Create Amazon SimpleDB Connector --------------------------------- Key: TEIID-1070 URL: https://jira.jboss.org/jira/browse/TEIID-1070 Project: Teiid Issue Type: Feature Request Components: Misc. Connectors Reporter: John Doyle Assignee: John Doyle Fix For: 7.1 We need connectivity to Amazon SimpleDB. This should be accomplished through a dedicated connector. Simple DB presents a few challenges as a Teiid source as it is more like a spreadsheet than a database. Simple DB "Domains' are like individual worksheets and contain any number of items. Items however can have any number of attributes, and the attributes do not have to be the same for ever item. So in a single Domain you can have an item with the attributes Size and Color, and another item with the attributes Color and ExpirationDate. This presents both modeling issues and SQL execution issues. None of them are insurmountable, but users will have to understand the issues and design their integration around them. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

4
6
0 / 0

[JBoss JIRA] Created: (TEIID-1311) Consider developing a connector/translator to Cassandra/Thrift

by Ken Johnson (JIRA)

Consider developing a connector/translator to Cassandra/Thrift -------------------------------------------------------------- Key: TEIID-1311 URL: https://jira.jboss.org/browse/TEIID-1311 Project: Teiid Issue Type: Feature Request Components: Misc. Connectors Affects Versions: 7.1 Environment: Any Reporter: Ken Johnson Assignee: Steven Hawkins Priority: Minor Apache Cassandra is starting to see uptake beyond the big name social network players. Has any thought been given to offering connectivity to Cassandra through Teiid? Perhaps this is through consuming the Thrift file as metadata source. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

3
3
0 / 0

[JBoss JIRA] Created: (TEIID-511) Make process plans serizializable.

by Steven Hawkins (JIRA)

Make process plans serizializable. ---------------------------------- Key: TEIID-511 URL: https://jira.jboss.org/jira/browse/TEIID-511 Project: Teiid Issue Type: Feature Request Components: Query Engine Affects Versions: 6.0.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 6.x Processing plans should be serializable to take advantage of replication and non-memory caches. See also TEIID-81 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (TEIID-1589) metadata per translator per request

by Mark Addleman (JIRA)

metadata per translator per request ----------------------------------- Key: TEIID-1589 URL: https://issues.jboss.org/browse/TEIID-1589 Project: Teiid Issue Type: Feature Request Reporter: Mark Addleman Assignee: Steven Hawkins Priority: Minor I'd like to the translator to attach metadata to the results it passes back to the Teiid JDBC client. For example, I'd like the translator to examine the connection object and decorate the returned data with which datasource provided the data. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

6
9
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues June 2011