February 2011 - teiid-issues - Jboss List Archives

[JBoss JIRA] Created: (TEIID-796) Allow for the import of overloaded procedures

by Steven Hawkins (JIRA)

Allow for the import of overloaded procedures --------------------------------------------- Key: TEIID-796 URL: https://jira.jboss.org/jira/browse/TEIID-796 Project: Teiid Issue Type: Feature Request Components: JDBC Connector Affects Versions: 6.2.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Priority: Minor Fix For: 6.3.0 Currently our metadata doesn't allow for the definition of overloaded procedures - however many sources supply unique names for each procedure signature that can be used instead of the base procedure name. -- 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

13 years, 8 months

2
7
0 / 0

[JBoss JIRA] Created: (TEIID-1473) Don't batch more rows than is needed when query contains limit but translator does not support limit

by Howard Abrams (JIRA)

Don't batch more rows than is needed when query contains limit but translator does not support limit ---------------------------------------------------------------------------------------------------- Key: TEIID-1473 URL: https://issues.jboss.org/browse/TEIID-1473 Project: Teiid Issue Type: Enhancement Reporter: Howard Abrams Assignee: Steven Hawkins Priority: Minor Teiid shouldn't try to batch more rows than is needed when query contains limit and translator does not support limit. For example, say there is a translator that exposes a table "A", but does not support limit. select * from A limit 2 will currently select an entire batch of rows (1024?) from A, instead of just stopping after 2 rows. Likewise, if the translator supports neither offset nor limit, and the query contains both, Teiid should not try to batch more that (offset + limit) rows. This is marked as "Minor" because the workaround of naively supporting limit and offset within a translator is not too hard. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
6
0 / 0

[JBoss JIRA] Created: (TEIID-1463) limit buffering for large results

by Steven Hawkins (JIRA)

limit buffering for large results --------------------------------- Key: TEIID-1463 URL: https://issues.jboss.org/browse/TEIID-1463 Project: Teiid Issue Type: Feature Request Components: Query Engine Affects Versions: 7.0 Reporter: Steven Hawkins Assignee: Steven Hawkins In a forward only scenario, if a client lags behind the server a buffer will still be built containing much of result. It would be good to limit the buffer size and prempt proactive processing when exceeded. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
3
0 / 0

[JBoss JIRA] Created: (TEIID-946) add support for in/out out return params

by Steven Hawkins (JIRA)

add support for in/out out return params ---------------------------------------- Key: TEIID-946 URL: https://jira.jboss.org/jira/browse/TEIID-946 Project: Teiid Issue Type: Feature Request Components: Query Engine Affects Versions: 8.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Priority: Minor Fix For: 8.0 In/out, out, return parameters should be supported in Teiid defined procedures - not just result sets. The logic for handling them would be similar to what exists for managing the update_count variable. The Designer would also need to remove validation restrictions preventing the usage of these parameters. -- 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

13 years, 8 months

1
3
0 / 0

[JBoss JIRA] Created: (TEIID-1329) API to force metadata read

by Mark Addleman (JIRA)

API to force metadata read -------------------------- Key: TEIID-1329 URL: https://jira.jboss.org/browse/TEIID-1329 Project: Teiid Issue Type: Feature Request Components: AdminApi Affects Versions: 7.1 Reporter: Mark Addleman Assignee: Steven Hawkins Priority: Minor We have a dynamic set of datasources that are accessed through Teiid. Each data source is represented as a different model within the VDB. Some data sources may not be available at the time Teiid executes the translator's getMetadata() method. When our code detects the data source is available, I'd like to poke Teiid to re-read the appropriate translator's metadata. -- 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

13 years, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (TEIID-1059) Add a specific translator for Ingres

by Steven Hawkins (JIRA)

Add a specific translator for Ingres ------------------------------------ Key: TEIID-1059 URL: https://jira.jboss.org/jira/browse/TEIID-1059 Project: Teiid Issue Type: Feature Request Components: JDBC Connector Affects Versions: 7.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 7.1 -- 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

13 years, 8 months

3
7
0 / 0

[JBoss JIRA] Created: (TEIID-1481) client url cleanups

by Steven Hawkins (JIRA)

client url cleanups ------------------- Key: TEIID-1481 URL: https://issues.jboss.org/browse/TEIID-1481 Project: Teiid Issue Type: Task Components: JDBC Driver Affects Versions: 7.4 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 7.4 Designer is now leveraging the TeiidURL class for validation of server urls. The messages need internationalized and it would be better to through a checked exception (such as MalformedUrlException) rather than IllegalArgumentException. In addition there is a lot of redundancy with url handling in the Socket/EmbeddedProfile, JDBCURL, and TeiidDataSource. This should be consolidated as much as possible. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (TEIID-1416) Admin console shows no information about sessions

by Boris Belovic (JIRA)

Admin console shows no information about sessions ------------------------------------------------- Key: TEIID-1416 URL: https://issues.jboss.org/browse/TEIID-1416 Project: Teiid Issue Type: Bug Components: AdminApi Affects Versions: 7.1 Reporter: Boris Belovic Assignee: Steven Hawkins Admin console shows no session information. The results table is empty even if the session is active (= connections to VDB weren't closed). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

4
10
0 / 0

[JBoss JIRA] Created: (TEIID-1479) Teiid Documentation does not include MS SQL Server as an available translator in section 10.2.2. JDBC Translator of the Reference Guide

by Van Halbert (JIRA)

Teiid Documentation does not include MS SQL Server as an available translator in section 10.2.2. JDBC Translator of the Reference Guide --------------------------------------------------------------------------------------------------------------------------------------- Key: TEIID-1479 URL: https://issues.jboss.org/browse/TEIID-1479 Project: Teiid Issue Type: Bug Components: Documentation Affects Versions: 7.4 Reporter: Van Halbert Assignee: Steven Hawkins Teiid Documentation does not include MS SQL Server as an available translator in section "10.2.2. JDBC Translato" of the Reference Guide. I checked versions 7.3 and 7.1. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (TEIID-1458) Wrong count(*) result when joining data from two models

by Claudio Venturini (JIRA)

Wrong count(*) result when joining data from two models ------------------------------------------------------- Key: TEIID-1458 URL: https://issues.jboss.org/browse/TEIID-1458 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 7.3, 7.2 Environment: Teiid 7.3 deployed on Jboss AS 5.1.0 GA running on Ubuntu Server 10.04 LTS, MySQL 5.1.51 running on the same maching as JBoss, SQL Server 2000 Standard SP4 running on Windows Server 2003 Reporter: Claudio Venturini Assignee: Steven Hawkins count(\*) gets a wrong result when is performed in a query which joins two tables coming from two different models. The first (named "sqlsrv") is a source model for a table stored in SQL Server 2000. The second (named "mysql") is a source model for a table stored in MySQl 5.1. The query performs an inner join on the column "product_id", which is shared by the two tables. All records match correctly, so there should be no difference in using an inner join instead of other join types. The query is the following: {noformat} SELECT invoice, invoice_date, code, sum(quantity) AS s, avg(price) AS av, count(*) AS dim FROM sqlsrv.test2.dbo.sales SL INNER JOIN mysql.test.product_code PC ON SL.product_id = PC.product_id GROUP BY invoice_date, invoice, code ORDER BY invoice_date ASC, invoice ASC, code ASC {noformat} The result of count(\*) is 1 for all records, while for some of them it should be 2, as there are duplicate records in the sales table, which are grouped by the GROUP BY clause. Note that the problem exists only with the inner join. Left, right and outer joins work well, even if the set of records that they produce is the same as that produced by the inner join. I noticed the problem in Teiid 7.2. Tonight I upgraded to 7.3, but the problem is still there. If the data are all in the same DB, the query works as expected. It is not significant in which of the two DB each table resides. I think it is neither a problem of the SQL Server connector, nor of the MySQL connector. The data are the following: *product_code*: ||code||category||product_id|| |1|1|125| |2|1|127| |3|1|123| |4|1|121| |5|1|126| |6|1|124| |7|1|122| *sales*: ||invoice||invoice_date||product_id||quantity||price|| |009831|2009-08-15 00:00:00|125|350|1.070261| |009831|2009-08-15 00:00:00|124|960|1.070261| |009843|2009-08-15 00:00:00|121|648|1.515264| |009843|2009-08-15 00:00:00|126|145|2.763902| |009843|2009-08-15 00:00:00|126|25|2.407148| |009855|2009-08-15 00:00:00|122|768|1.122835| |009855|2009-08-15 00:00:00|123|540|1.158511| |009855|2009-08-15 00:00:00|125|480|1.070261| |009857|2009-08-15 00:00:00|122|440|1.498365| |009857|2009-08-15 00:00:00|126|115|2.585525| |009866|2009-08-15 00:00:00|122|736|1.498365| |009866|2009-08-15 00:00:00|123|558|1.391339| |009866|2009-08-15 00:00:00|125|378|1.336887| |009866|2009-08-15 00:00:00|127|510|1.605391| |009866|2009-08-15 00:00:00|126|435|2.585525| |009847|2009-08-15 00:00:00|126|55|2.763902| |009847|2009-08-15 00:00:00|126|5|2.407148| |009847|2009-08-15 00:00:00|121|240|1.872018| The result of the above query is: ||invoice||invoice_date||code||s||av||dim|| |009831|2009-08-15 00:00:00|1|350.0|1.070261|1| |009831|2009-08-15 00:00:00|6|960.0|1.070261|1| |009843|2009-08-15 00:00:00|4|648.0|1.515264|1| |009843|2009-08-15 00:00:00|5|170.0|2.585525|1| |009847|2009-08-15 00:00:00|4|240.0|1.872018|1| |009847|2009-08-15 00:00:00|5|60.0|2.585525|1| |009855|2009-08-15 00:00:00|1|480.0|1.070261|1| |009855|2009-08-15 00:00:00|3|540.0|1.158511|1| |009855|2009-08-15 00:00:00|7|768.0|1.122835|1| |009857|2009-08-15 00:00:00|5|115.0|2.585525|1| |009857|2009-08-15 00:00:00|7|440.0|1.498365|1| |009866|2009-08-15 00:00:00|1|378.0|1.336887|1| |009866|2009-08-15 00:00:00|2|510.0|1.605391|1| |009866|2009-08-15 00:00:00|3|558.0|1.391339|1| |009866|2009-08-15 00:00:00|5|435.0|2.585525|1| |009866|2009-08-15 00:00:00|7|736.0|1.498365|1| As you can see, count(\*) (the "dim" column) always returns 1, even if it should return 2 for the product with id 126 in invoices 009843 and 009847. If needed, I can provide you the two source models, and a dump of the two DBs. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
12
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues February 2011