May 2011 - teiid-issues - Jboss List Archives

[JBoss JIRA] Created: (TEIID-1508) Dependent join planning problem

by Steven Hawkins (JIRA)

Dependent join planning problem ------------------------------- Key: TEIID-1508 URL: https://issues.jboss.org/browse/TEIID-1508 Project: Teiid Issue Type: Quality Risk Components: Query Engine Affects Versions: 7.4 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 7.4 Without a dependent join hint a composite cross source dependent join will not plan correctly unless the independent side can be pushed as a single query. The root of the issue is that join planning involving more than 1 independent table does not consider the effect of potential dependent joins early enough. The workaround is to use a dependent join hint or set the cardinality of the independent tables small enough to trigger the proper dependent join. -- 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] Closed: (TEIID-1443) SalesForce connector execution of procedure fails with NPE

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-1443?page=com.atlassian.jira.plugin... ] Steven Hawkins closed TEIID-1443. --------------------------------- > SalesForce connector execution of procedure fails with NPE > ---------------------------------------------------------- > > Key: TEIID-1443 > URL: https://issues.jboss.org/browse/TEIID-1443 > Project: Teiid > Issue Type: Bug > Components: Salesforce Connector > Affects Versions: 7.1.1 > Environment: RHEL 5 > Reporter: Paul Nittel > Assignee: Steven Hawkins > Fix For: 7.3 > > > I executed this query from SQuirreL: > exec sf.salesforce.getupdated('Lead', {ts'2011-01-18 11:42:10.5'}, {ts'2011-01-19 10:42:10.5'}) > And the server burped out this: > 2011-01-19 10:16:10,805 ERROR [org.teiid.PROCESSOR] (Worker30_QueryProcessorQueue639) Unexpected exception for request cFDOigVAx+GT.9 > java.lang.NullPointerException > at org.teiid.translator.salesforce.execution.ProcedureExecutionParentImpl.next(ProcedureExecutionParentImpl.java:37) > at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.handleBatch(ConnectorWorkItem.java:281) > at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:266) > at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:281) > at org.teiid.dqp.internal.process.DataTierTupleSource.access$000(DataTierTupleSource.java:71) > at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:123) > at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:120) > at org.teiid.dqp.internal.process.DQPCore$FutureWork.run(DQPCore.java:108) > at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:188) > at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:116) > at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:290) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:619) > 2011-01-19 10:16:10,805 ERROR [org.teiid.CONNECTOR] (Worker29_QueryProcessorQueue640) > java.lang.NullPointerException > at org.teiid.translator.salesforce.execution.ProcedureExecutionParentImpl.close(ProcedureExecutionParentImpl.java:47) > at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.close(ConnectorWorkItem.java:146) > at org.teiid.dqp.internal.process.DataTierTupleSource$5.call(DataTierTupleSource.java:322) > at org.teiid.dqp.internal.process.DataTierTupleSource$5.call(DataTierTupleSource.java:319) > at org.teiid.dqp.internal.process.DQPCore$FutureWork.run(DQPCore.java:108) > at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:188) > at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:116) > at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:290) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:619) > SQuirreL just reported: > Error: org.teiid.core.TeiidException > SQLState: 38000 > ErrorCode: 0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
0
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

[JBoss JIRA] Closed: (TEIID-229) Support update of the view column using a column

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-229?page=com.atlassian.jira.plugin.... ] Steven Hawkins closed TEIID-229. -------------------------------- > Support update of the view column using a column > ------------------------------------------------ > > Key: TEIID-229 > URL: https://issues.jboss.org/browse/TEIID-229 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Li Liang > Assignee: Steven Hawkins > Fix For: 7.3 > > > This is related to case 176903. We do not support the update of a view column using a column instead of a constant (or expression that can be evaluated to a constant). e.g. update view1 set c1=c2. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (TEIID-1502) ODBC (and admin) scalability limited by maxWorker cap

by Steven Hawkins (JIRA)

ODBC (and admin) scalability limited by maxWorker cap ----------------------------------------------------- Key: TEIID-1502 URL: https://issues.jboss.org/browse/TEIID-1502 Project: Teiid Issue Type: Bug Components: Server Affects Versions: 7.1 Reporter: Steven Hawkins Assignee: Steven Hawkins Priority: Critical Fix For: 7.4 We are capping the max workers in an attempt to prevent excessive thread use, but this prevents the blocking operations of ODBC/admin to scale well. The long term fix is to make ODBC/admin operations non-blocking wrt the IO. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (TEIID-1482) Prevent unnecessary rebuffering of sorted results

by Steven Hawkins (JIRA)

Prevent unnecessary rebuffering of sorted results ------------------------------------------------- Key: TEIID-1482 URL: https://issues.jboss.org/browse/TEIID-1482 Project: Teiid Issue Type: Enhancement Components: Query Engine Affects Versions: 7.4 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 7.4 A plan that has a final (non-unrelated sort) sort will have the results rebuffered by the RequestWorkItem even though they are should already be available in a buffer. -- 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-1082) simple vdbless editor

by Mauricio Chicalski (JIRA)

simple vdbless editor --------------------- Key: TEIID-1082 URL: https://jira.jboss.org/jira/browse/TEIID-1082 Project: Teiid Issue Type: Feature Request Components: AdminApi Affects Versions: 7.0 Reporter: Mauricio Chicalski Assignee: Steven Hawkins Priority: Optional helper classes (vdbless beans?) and methods to create/manipulate vdbless files within the admin api c.setUrl("jdbc:...."); model.setName model.setConnector(c); vdb.setConnector(c); admin.createVDB(vdb); -- 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
4
0 / 0

[JBoss JIRA] Created: (TEIID-1480) Teiid's ODBC interaction with PostgreSQL-ODBC fails when column lengths exceed 64K as PostgreSQL stores these values as a short

by Paul Nittel (JIRA)

Teiid's ODBC interaction with PostgreSQL-ODBC fails when column lengths exceed 64K as PostgreSQL stores these values as a short ------------------------------------------------------------------------------------------------------------------------------- Key: TEIID-1480 URL: https://issues.jboss.org/browse/TEIID-1480 Project: Teiid Issue Type: Bug Reporter: Paul Nittel Assignee: Steven Hawkins I imported the AdventureWorks2000 database from SQL Server. I had a simple VDB which contained this model. In Excel I was able to see the basic metadata (names of tables), but trying to do anything with a column caused an error. The server.log reported: 2011-02-23 10:15:50,330 ERROR [org.teiid.PROCESSOR.MATVIEWS] (Worker6_QueryProcessorQueue146) Failed to load materialized view table #MAT_PG_CATALOG.PG_ATTRIBUTE. [ExpressionEvaluationException] ERR.015.001.0003: Error Code:ERR.015.001.0003 Message:Unable to evaluate convert(t1__1.Length, short): Error Code:ERR.015.001.0003 Message:Error while evaluating function convert 1 [FunctionExecutionException] ERR.015.001.0003: Error Code:ERR.015.001.0003 Message:Error while evaluating function convert 2 [FunctionExecutionException] ERR.015.001.0033: Error Code:ERR.015.001.0033 Message:Error converting [2,147,483,647] of type integer to type short 3 [TransformationException]The Integer value '2,147,483,647' is outside the of range for Short at org.teiid.query.eval.Evaluator.evaluate(Evaluator.java:605) at org.teiid.query.processor.relational.ProjectNode.updateTuple(ProjectNode.java:218) at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:181) at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:274) at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:107) at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:150) at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:105) at org.teiid.query.processor.BatchCollector$BatchProducerTupleSource.nextTuple(BatchCollector.java:71) at org.teiid.query.tempdata.TempTable$UpdateProcessor.process(TempTable.java:205) at org.teiid.query.tempdata.TempTable.insert(TempTable.java:446) at org.teiid.query.tempdata.TempTableDataManager.loadGlobalTable(TempTableDataManager.java:516) at org.teiid.query.tempdata.TempTableDataManager.registerQuery(TempTableDataManager.java:410) at org.teiid.query.tempdata.TempTableDataManager.registerRequest(TempTableDataManager.java:182) at org.teiid.query.tempdata.TempTableDataManager.registerRequest(TempTableDataManager.java:170) at org.teiid.query.processor.relational.AccessNode.registerRequest(AccessNode.java:197) at org.teiid.query.processor.relational.AccessNode.open(AccessNode.java:118) at org.teiid.query.processor.relational.JoinStrategy.openRight(JoinStrategy.java:102) at org.teiid.query.processor.relational.JoinNode.open(JoinNode.java:141) at org.teiid.query.processor.relational.JoinStrategy.openLeft(JoinStrategy.java:92) at org.teiid.query.processor.relational.JoinNode.open(JoinNode.java:138) at org.teiid.query.processor.relational.JoinStrategy.openLeft(JoinStrategy.java:92) at org.teiid.query.processor.relational.JoinNode.open(JoinNode.java:138) at org.teiid.query.processor.relational.RelationalNode.open(RelationalNode.java:250) at org.teiid.query.processor.relational.JoinStrategy.openLeft(JoinStrategy.java:92) at org.teiid.query.processor.relational.JoinNode.open(JoinNode.java:138) at org.teiid.query.processor.relational.RelationalNode.open(RelationalNode.java:250) at org.teiid.query.processor.relational.RelationalNode.open(RelationalNode.java:250) at org.teiid.query.processor.relational.RelationalPlan.open(RelationalPlan.java:98) at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:134) at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:105) at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:115) at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:250) at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:184) at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:49) at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:188) at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:116) at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:290) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) The pg_attribute field was modeled as a short to conform to PostgreSQL. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

3
2
0 / 0

[JBoss JIRA] Created: (TEIID-1487) CLONE - Add implicit conversion of NULL to correct datatype in transformation validator

by Steven Hawkins (JIRA)

CLONE - Add implicit conversion of NULL to correct datatype in transformation validator --------------------------------------------------------------------------------------- Key: TEIID-1487 URL: https://issues.jboss.org/browse/TEIID-1487 Project: Teiid Issue Type: Feature Request Components: Query Engine Affects Versions: 6.0.0 Reporter: Marc Shirley When using NULL value as a column (ie, NULL as columnName), it is only implicitly converted to a string. When trying to use the NULL as a column of type date, integer, float, etc., the validator throws a warning that the transformation is not valid. If you wrap the NULL in a convert to the correct column datatype (ie, "convert(NULL,date)"), the transformation can be validated successfully. -- 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-1061) Add a specific translator for SAP Business Warehouse

by Steven Hawkins (JIRA)

Add a specific translator for SAP Business Warehouse ---------------------------------------------------- Key: TEIID-1061 URL: https://jira.jboss.org/jira/browse/TEIID-1061 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

4
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues May 2011