October 2009 - teiid-issues - Jboss List Archives

[JBoss JIRA] Created: (TEIID-700) Adding ORDER BY to a specific query (see details) gets ORA-00904: "C_0": invalid identifier

by Paul Nittel (JIRA)

Adding ORDER BY to a specific query (see details) gets ORA-00904: "C_0": invalid identifier ------------------------------------------------------------------------------------------- Key: TEIID-700 URL: https://jira.jboss.org/jira/browse/TEIID-700 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 6.1.0 Environment: Fedora 10, OpenJDK 1.6.0, Teiid 6.1.0 Reporter: Paul Nittel Assignee: Steven Hawkins I created a query which worked fine until I added the ORDER BY clause: (SELECT INTKEY, 'A' AS WHEREFROM FROM BQT1.SMALLA LIMIT 6) UNION ALL (SELECT INTKEY, 'B' AS WHEREFROM FROM BQT2.SMALLB LIMIT 5) ORDER BY INTKEY, WHEREFROM LIMIT 10 Now, when executed, it generates this: Jul 01, 2009 10:37:09.727 [Worker5_QueryProcessorQueue47|0] ERROR <DQP|0> Unexpected exception for request 0.16 [MetaMatrixComponentException] 904: Error Code:904 Message:Error Code:904 Message:Error occurred on connector BQT1 Connector<8> - Error Code:904 Message:ORA-00904: "C_0": invalid identifier Executing statement: [SQL: SELECT * FROM (SELECT g_1.IntKey AS c_0, 'A' AS c_1 FROM SmallA g_1) WHERE ROWNUM <= 6 UNION ALL SELECT * FROM (SELECT g_0.IntKey AS c_0, 'B' AS c_1 FROM SmallB g_0) WHERE ROWNUM <= 5 ORDER BY c_0, c_1] 1 [ConnectorException]Error Code:904 Message:Error occurred on connector BQT1 Connector<8> - Error Code:904 Message:ORA-00904: "C_0": invalid identifier Executing statement: [SQL: SELECT * FROM (SELECT g_1.IntKey AS c_0, 'A' AS c_1 FROM SmallA g_1) WHERE ROWNUM <= 6 UNION ALL SELECT * FROM (SELECT g_0.IntKey AS c_0, 'B' AS c_1 FROM SmallB g_0) WHERE ROWNUM <= 5 ORDER BY c_0, c_1] 2 [JDBCExecutionException]Error Code:904 Message:ORA-00904: "C_0": invalid identifier Executing statement: [SQL: SELECT * FROM (SELECT g_1.IntKey AS c_0, 'A' AS c_1 FROM SmallA g_1) WHERE ROWNUM <= 6 UNION ALL SELECT * FROM (SELECT g_0.IntKey AS c_0, 'B' AS c_1 FROM SmallB g_0) WHERE ROWNUM <= 5 ORDER BY c_0, c_1] at org.teiid.dqp.internal.process.DataTierTupleSource.switchBatch(DataTierTupleSource.java:128) at org.teiid.dqp.internal.process.DataTierTupleSource.nextTuple(DataTierTupleSource.java:89) at com.metamatrix.query.processor.relational.AccessNode.nextBatchDirect(AccessNode.java:136) at com.metamatrix.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:257) at com.metamatrix.query.processor.relational.LimitNode.nextBatchDirect(LimitNode.java:81) at com.metamatrix.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:257) at com.metamatrix.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:110) at com.metamatrix.query.processor.QueryProcessor.process(QueryProcessor.java:160) at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:264) at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:210) at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:44) at com.metamatrix.common.queue.WorkerPoolFactory$StatsCapturingSharedThreadPoolExecutor$1.run(WorkerPoolFactory.java:211) 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) Caused by: org.teiid.connector.api.ConnectorException: Error Code:904 Message:Error occurred on connector BQT1 Connector<8> - Error Code:904 Message:ORA-00904: "C_0": invalid identifier Executing statement: [SQL: SELECT * FROM (SELECT g_1.IntKey AS c_0, 'A' AS c_1 FROM SmallA g_1) WHERE ROWNUM <= 6 UNION ALL SELECT * FROM (SELECT g_0.IntKey AS c_0, 'B' AS c_1 FROM SmallB g_0) WHERE ROWNUM <= 5 ORDER BY c_0, c_1] at org.teiid.dqp.internal.datamgr.impl.ConnectorWorkItem.handleError(ConnectorWorkItem.java:235) at org.teiid.dqp.internal.datamgr.impl.ConnectorWorkItem.process(ConnectorWorkItem.java:174) at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:44) at org.teiid.dqp.internal.datamgr.impl.SynchConnectorWorkItem.run(SynchConnectorWorkItem.java:69) ... 4 more Caused by: org.teiid.connector.jdbc.JDBCExecutionException: Error Code:904 Message:ORA-00904: "C_0": invalid identifier Executing statement: [SQL: SELECT * FROM (SELECT g_1.IntKey AS c_0, 'A' AS c_1 FROM SmallA g_1) WHERE ROWNUM <= 6 UNION ALL SELECT * FROM (SELECT g_0.IntKey AS c_0, 'B' AS c_1 FROM SmallB g_0) WHERE ROWNUM <= 5 ORDER BY c_0, c_1] at org.teiid.connector.jdbc.JDBCQueryExecution.execute(JDBCQueryExecution.java:103) at org.teiid.dqp.internal.datamgr.impl.ConnectorWorkItem.processNewRequest(ConnectorWorkItem.java:277) at org.teiid.dqp.internal.datamgr.impl.ConnectorWorkItem.process(ConnectorWorkItem.java:157) ... 6 more Steve Hawkins suspects the OracleTranslator code. -- 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

16 years

2
5
0 / 0

[JBoss JIRA] Created: (TEIID-710) DB2 does not support pushdown of null keyword as a select expression

by Steven Hawkins (JIRA)

DB2 does not support pushdown of null keyword as a select expression -------------------------------------------------------------------- Key: TEIID-710 URL: https://jira.jboss.org/jira/browse/TEIID-710 Project: Teiid Issue Type: Bug Components: JDBC Connector Affects Versions: 6.1.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Priority: Minor Fix For: 6.2.0 For example SELECT SmallA.IntKey, NULL FROM SmallA will fail. -- 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

16 years

1
2
0 / 0

[JBoss JIRA] Created: (TEIID-360) SQLServer SQLTranslator issues

by Steven Hawkins (JIRA)

SQLServer SQLTranslator issues ------------------------------ Key: TEIID-360 URL: https://jira.jboss.org/jira/browse/TEIID-360 Project: Teiid Issue Type: Bug Components: JDBC Connector Affects Versions: 6.0.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 6.0.0 The time literal for Access/SQLServer is incorrect - should use 1970 not 1900 Limit for a set op needs to use a subquery Support for repeat should be aliased to replicate -- 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

16 years

1
7
0 / 0

[JBoss JIRA] Created: (TEIID-455) Config edits should use optimistic locking

by Steven Hawkins (JIRA)

Config edits should use optimistic locking ------------------------------------------ Key: TEIID-455 URL: https://jira.jboss.org/jira/browse/TEIID-455 Project: Teiid Issue Type: Bug Affects Versions: 6.1.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 6.x Config edits are atomic, but do not enforce consistency - the last one always wins. Optimistic locking should be used to properly ensure consistency. Also versions should be restorable. Currently it's not expected that multiple admins will be making changes concurrently, so this is not a critical issue. -- 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

16 years

1
3
0 / 0

[JBoss JIRA] Updated: (TEIID-160) Remove redundant self-joins

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-160?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-160: --------------------------------- Fix Version/s: 7.0 (was: 6.3) > Remove redundant self-joins > --------------------------- > > Key: TEIID-160 > URL: https://jira.jboss.org/jira/browse/TEIID-160 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 7.x > Reporter: Steven Hawkins > Priority: Minor > Fix For: 7.0 > > Original Estimate: 2 days > Remaining Estimate: 2 days > > Query minimization should be used to remove self-joins on unique columns. This could be added as part of RuleRemoveOptionalJoins (but the rule may need to be run again after join planning). -- 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

16 years, 5 months

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-102) Metadata search with * or ? may return the wrong results

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-102?page=com.atlassian.jira.plug... ] Steven Hawkins resolved TEIID-102. ---------------------------------- Resolution: Out of Date The index connector has been removed. > Metadata search with * or ? may return the wrong results > -------------------------------------------------------- > > Key: TEIID-102 > URL: https://jira.jboss.org/jira/browse/TEIID-102 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 7.x > Reporter: Steven Hawkins > Priority: Optional > Fix For: 7.0 > > > Defect Tracker #24869: Searches through the metadata connector are supposed to support like criteria, however this is no way in the index pattern logic to escape * or ?, so any query that is searching explicitly for those values will instead get the values as if they were wildcards. -- 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

16 years, 5 months

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-254) Metadata query for procedure columns needs work

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-254?page=com.atlassian.jira.plug... ] Steven Hawkins resolved TEIID-254. ---------------------------------- Resolution: Done The query for procedure params is now a physical query off of the object model. > Metadata query for procedure columns needs work > ----------------------------------------------- > > Key: TEIID-254 > URL: https://jira.jboss.org/jira/browse/TEIID-254 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Priority: Minor > Fix For: 6.3 > > > Defect Tracker #24885: Even if procedure name criteria is supplied for the QUERY_PROCEDURE_COLUMNS, it is applied to a synthetic column - which can only be processed after all rows are retrieved. It looks like there may be other procedure name values in the system tables that would be a better place for this criteria (or at least more join criteria could be added under the ProcedureParams query) -- 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

16 years, 5 months

1
0
0 / 0

[JBoss JIRA] Commented: (TEIID-217) LDAP Connector should provide a way to retrieve all values of an attribute that appears multiple times within a search result

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-217?page=com.atlassian.jira.plug... ] Steven Hawkins commented on TEIID-217: -------------------------------------- Mike, are you unsure if you want this approach included in Teiid? I agree with the issue discription that other approaches for the multivalued attributes would be better - such as additional tables with an explicit join or a user_dn table that is already joined with its parent - "select value, group_dn from user_dn where value like '%abc%'". However since that affects the importer there is understandably more work. > LDAP Connector should provide a way to retrieve all values of an attribute that appears multiple times within a search result > ----------------------------------------------------------------------------------------------------------------------------- > > Key: TEIID-217 > URL: https://jira.jboss.org/jira/browse/TEIID-217 > Project: Teiid > Issue Type: Feature Request > Components: LDAP Connector > Affects Versions: 6.0.0 > Reporter: Michael Walker > Priority: Minor > Fix For: 6.3 > > > If an attribute appears more than once, we should have some way to return all values. Currently, we only return one value, with no rhyme, reason, or determinism as to which one gets returned. Implementing this is difficult when multiple attributes appear more than once, of course. But a simple example of where this problem rears it's head is in modeling LDAP groups. Groups typically have repeating attributes to represent each member, and it would be nice to query all members of a given group, but impossible to do so with the current logic. > A sophisticated solution would create a normalized view of a DN, breaking out multi-valued attributes into a separate table that could be joined by a primary key. A simple solution might allow attributes to be flagged as "multi-valued", in which case, they could be maintained in a single denormalized table that represents all values in the DN. > If we build an importer for LDAP, we should consider how to best handle this issue in the importer design. -- 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

16 years, 5 months

1
0
0 / 0

[JBoss JIRA] Commented: (TEIID-217) LDAP Connector should provide a way to retrieve all values of an attribute that appears multiple times within a search result

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-217?page=com.atlassian.jira.plug... ] Steven Hawkins commented on TEIID-217: -------------------------------------- Mike, are you unsure if you want this approach included in Teiid? I agree with the issue discription that other approaches for the multivalued attributes would be better - such as additional tables with an explicit join or a user_dn table that is already joined with its parent - "select value, group_dn from user_dn where value like '%abc%'". However since that affects the importer there is understandably more work. > LDAP Connector should provide a way to retrieve all values of an attribute that appears multiple times within a search result > ----------------------------------------------------------------------------------------------------------------------------- > > Key: TEIID-217 > URL: https://jira.jboss.org/jira/browse/TEIID-217 > Project: Teiid > Issue Type: Feature Request > Components: LDAP Connector > Affects Versions: 6.0.0 > Reporter: Michael Walker > Priority: Minor > Fix For: 6.3 > > > If an attribute appears more than once, we should have some way to return all values. Currently, we only return one value, with no rhyme, reason, or determinism as to which one gets returned. Implementing this is difficult when multiple attributes appear more than once, of course. But a simple example of where this problem rears it's head is in modeling LDAP groups. Groups typically have repeating attributes to represent each member, and it would be nice to query all members of a given group, but impossible to do so with the current logic. > A sophisticated solution would create a normalized view of a DN, breaking out multi-valued attributes into a separate table that could be joined by a primary key. A simple solution might allow attributes to be flagged as "multi-valued", in which case, they could be maintained in a single denormalized table that represents all values in the DN. > If we build an importer for LDAP, we should consider how to best handle this issue in the importer design. -- 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

16 years, 5 months

1
0
0 / 0

[JBoss JIRA] Commented: (TEIID-217) LDAP Connector should provide a way to retrieve all values of an attribute that appears multiple times within a search result

by Michael Walker (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-217?page=com.atlassian.jira.plug... ] Michael Walker commented on TEIID-217: -------------------------------------- FYI, I implemented the multivalued-concat approach ( return a single row with an ordered, delimited list of all values) as a test, and it generally works, with the caveat that returning all values can take a long time. For example select group_dn, user_dn from groups where user_dn like '%abc% where the user DN is the multi-valued attribute, can be time-consuming if the user is in a large number of groups, and those groups have many members. It's worth noting that in this example, the LIKE criteria is pushed down, so the list of groups can be quickly returned. However, it's the population of the user_dn string that takes a long time, since each grab of the next multivalued attribute is a separate outcall. Perhaps this can be tuned, just thought I'd add it to the case notes, ping me if you want the implementation details. > LDAP Connector should provide a way to retrieve all values of an attribute that appears multiple times within a search result > ----------------------------------------------------------------------------------------------------------------------------- > > Key: TEIID-217 > URL: https://jira.jboss.org/jira/browse/TEIID-217 > Project: Teiid > Issue Type: Feature Request > Components: LDAP Connector > Affects Versions: 6.0.0 > Reporter: Michael Walker > Priority: Minor > Fix For: 6.3 > > > If an attribute appears more than once, we should have some way to return all values. Currently, we only return one value, with no rhyme, reason, or determinism as to which one gets returned. Implementing this is difficult when multiple attributes appear more than once, of course. But a simple example of where this problem rears it's head is in modeling LDAP groups. Groups typically have repeating attributes to represent each member, and it would be nice to query all members of a given group, but impossible to do so with the current logic. > A sophisticated solution would create a normalized view of a DN, breaking out multi-valued attributes into a separate table that could be joined by a primary key. A simple solution might allow attributes to be flagged as "multi-valued", in which case, they could be maintained in a single denormalized table that represents all values in the DN. > If we build an importer for LDAP, we should consider how to best handle this issue in the importer design. -- 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

16 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues October 2009