February 2010 - teiid-issues - Jboss List Archives

[JBoss JIRA] Moved: (TEIID-954) Need method to controll max amount of bufer disk space

by Van Halbert (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-954?page=com.atlassian.jira.plug... ] Van Halbert moved JBEDSP-1154 to TEIID-954: ------------------------------------------- Project: Teiid (was: JBoss Enterprise Data Services Platform) Key: TEIID-954 (was: JBEDSP-1154) Component/s: Query Engine (was: Server) (was: Query) Fix Version/s: (was: Westport) Affects Version/s: (was: 5.5) … [View More]

15 years, 1 month

1
0
0 / 0

[JBoss JIRA] Moved: (TEIID-953) document the use of cluster.key

by Van Halbert (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-953?page=com.atlassian.jira.plug... ] Van Halbert moved JBEDSP-852 to TEIID-953: ------------------------------------------ Project: Teiid (was: JBoss Enterprise Data Services Platform) Key: TEIID-953 (was: JBEDSP-852) Component/s: Documentation (was: Documentation) Fix Version/s: (was: Westport) Affects Version/s: 7.1 (was: Westport) &… [View More]

15 years, 1 month

1
0
0 / 0

[JBoss JIRA] Moved: (TEIID-952) Column level security capabilities

by Van Halbert (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-952?page=com.atlassian.jira.plug... ] Van Halbert moved JBEDSP-1153 to TEIID-952: ------------------------------------------- Project: Teiid (was: JBoss Enterprise Data Services Platform) Key: TEIID-952 (was: JBEDSP-1153) Component/s: Query Engine (was: Server) Fix Version/s: (was: Westport) Affects Version/s: (was: 5.5.2) > Column level security … [View More]

15 years, 1 month

1
0
0 / 0

[JBoss JIRA] Moved: (TEIID-951) Add/Verify ipv6 readiness

by Van Halbert (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-951?page=com.atlassian.jira.plug... ] Van Halbert moved JBEDSP-20 to TEIID-951: ----------------------------------------- Project: Teiid (was: JBoss Enterprise Data Services Platform) Key: TEIID-951 (was: JBEDSP-20) Component/s: Documentation Query Engine (was: Documentation) (was: Connectors) (was: … [View More]

15 years, 1 month

1
0
0 / 0

[JBoss JIRA] Moved: (TEIID-950) Add ability to control access to environment variables

by Van Halbert (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-950?page=com.atlassian.jira.plug... ] Van Halbert moved JBEDSP-19 to TEIID-950: ----------------------------------------- Project: Teiid (was: JBoss Enterprise Data Services Platform) Key: TEIID-950 (was: JBEDSP-19) Component/s: Query Engine (was: Server) Fix Version/s: (was: Westport) Affects Version/s: (was: 5.5.1) (was: 5.5) > … [View More]

15 years, 1 month

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-949) Criteria on constant column with aggregate function doesn't push criteria down correctly

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-949?page=com.atlassian.jira.plug... ] Steven Hawkins resolved TEIID-949. ---------------------------------- Resolution: Done Added a check in RulePushSelectCriteria to prevent this case. > Criteria on constant column with aggregate function doesn't push criteria down correctly > ---------------------------------------------------------------------------------------- > > Key: TEIID-949 > URL: https:… [View More]//jira.jboss.org/jira/browse/TEIID-949 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 6.0.0 > Environment: MM5.5.4 > Reporter: Larry O'Leary > Assignee: Steven Hawkins > Fix For: 7.0 > > > When a column value is a constant and used along with an aggregate, criteria on the constant column is being ignored. Here is an example query: > SELECT * FROM ( > SELECT b.count, enterprise_id FROM ( > SELECT COUNT(*), 35 AS enterprise_id FROM ( > SELECT "A Name" AS Name, 37 AS enterprise_id > ) c > ) b > ) a WHERE enterprise_id = 1 OPTION DEBUG > The expected result is an empty result set. Instead, the result set comes back as: > COUNT, ENTERPRISE_ID > 0, 35 > The resulting plan looks like: > OPTIMIZATION COMPLETE: > PLAN TREE: > (type=Relational, command=SELECT * FROM (SELECT b."count", enterprise_id FROM (SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c) AS b) AS a WHERE enterprise_id = 1 OPTION DEBUG, props={0=PlanHints}) > canonical plan: > Project(groups=[b], props={90=[b."count", enterprise_id], 30=[b."count", enterprise_id], 114=0.0, 91=[A."COUNT", A.ENTERPRISE_ID]}) > Source(groups=[b], props={90=[b."count", enterprise_id], 64=SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c, 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}}) > Project(groups=[], props={90=[b."count", enterprise_id], 30=[COUNT(*), 35 AS enterprise_id], 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}, 91=[COUNT(*), 35 AS enterprise_id]}) > Group(groups=[c], props={90=[COUNT(*)], 114=0.0, 81=[COUNT(*)]}) > Null(groups=[c], props={90=[], 114=0.0}) > PROCESSOR PLAN: > ProjectNode(1) output=[b."count", enterprise_id] [b."count", enterprise_id] > ProjectNode(2) output=[b."count", enterprise_id] [COUNT(*), 35 AS enterprise_id] > GroupingNode(3) output=[COUNT(*)] null > NullNode(4) output=[] > If the query is changed as follows, the expected result is received: > SELECT * FROM ( > SELECT b.count, enterprise_id FROM ( > SELECT COUNT(*), 35 AS enterprise_id FROM ( > SELECT "A Name" AS Name, 37 AS enterprise_id > ) c GROUP BY enterprise_id > ) b > ) a WHERE enterprise_id = 1 OPTION DEBUG > Which yields a very similar plan: > PLAN TREE: > (type=Relational, command=SELECT * FROM (SELECT b."count", enterprise_id FROM (SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c GROUP BY enterprise_id) AS b) AS a WHERE enterprise_id = 1 OPTION DEBUG, props={0=PlanHints}) > canonical plan: > Project(groups=[b], props={90=[b."count", enterprise_id], 30=[b."count", enterprise_id], 114=0.0, 91=[A."COUNT", A.ENTERPRISE_ID]}) > Source(groups=[b], props={90=[b."count", enterprise_id], 64=SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c GROUP BY enterprise_id, 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}}) > Project(groups=[], props={90=[b."count", enterprise_id], 30=[COUNT(*), 35 AS enterprise_id], 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}, 91=[COUNT(*), 35 AS enterprise_id]}) > Group(groups=[c], props={90=[COUNT(*)], 114=0.0, 80=[enterprise_id], 81=[COUNT(*)]}) > Null(groups=[c], props={90=[enterprise_id], 114=0.0}) > PROCESSOR PLAN: > ProjectNode(1) output=[b."count", enterprise_id] [b."count", enterprise_id] > ProjectNode(2) output=[b."count", enterprise_id] [COUNT(*), 35 AS enterprise_id] > GroupingNode(3) output=[COUNT(*)] [enterprise_id] > NullNode(4) output=[enterprise_id] > Except the NullNode node contains enterprise_id as its target column vs an empty value. -- 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 [View Less]

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-949) Criteria on constant column with aggregate function doesn't push criteria down correctly

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-949?page=com.atlassian.jira.plug... ] Steven Hawkins updated TEIID-949: --------------------------------- Fix Version/s: 7.0 Affects Version/s: 6.0.0 (was: 7.0) Assignee: Steven Hawkins (was: Larry O'Leary) > Criteria on constant column with aggregate function doesn't push criteria down correctly > ---------------------------------------------------------------------------------------- > … [View More]> Key: TEIID-949 > URL: https://jira.jboss.org/jira/browse/TEIID-949 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 6.0.0 > Environment: MM5.5.4 > Reporter: Larry O'Leary > Assignee: Steven Hawkins > Fix For: 7.0 > > > When a column value is a constant and used along with an aggregate, criteria on the constant column is being ignored. Here is an example query: > SELECT * FROM ( > SELECT b.count, enterprise_id FROM ( > SELECT COUNT(*), 35 AS enterprise_id FROM ( > SELECT "A Name" AS Name, 37 AS enterprise_id > ) c > ) b > ) a WHERE enterprise_id = 1 OPTION DEBUG > The expected result is an empty result set. Instead, the result set comes back as: > COUNT, ENTERPRISE_ID > 0, 35 > The resulting plan looks like: > OPTIMIZATION COMPLETE: > PLAN TREE: > (type=Relational, command=SELECT * FROM (SELECT b."count", enterprise_id FROM (SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c) AS b) AS a WHERE enterprise_id = 1 OPTION DEBUG, props={0=PlanHints}) > canonical plan: > Project(groups=[b], props={90=[b."count", enterprise_id], 30=[b."count", enterprise_id], 114=0.0, 91=[A."COUNT", A.ENTERPRISE_ID]}) > Source(groups=[b], props={90=[b."count", enterprise_id], 64=SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c, 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}}) > Project(groups=[], props={90=[b."count", enterprise_id], 30=[COUNT(*), 35 AS enterprise_id], 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}, 91=[COUNT(*), 35 AS enterprise_id]}) > Group(groups=[c], props={90=[COUNT(*)], 114=0.0, 81=[COUNT(*)]}) > Null(groups=[c], props={90=[], 114=0.0}) > PROCESSOR PLAN: > ProjectNode(1) output=[b."count", enterprise_id] [b."count", enterprise_id] > ProjectNode(2) output=[b."count", enterprise_id] [COUNT(*), 35 AS enterprise_id] > GroupingNode(3) output=[COUNT(*)] null > NullNode(4) output=[] > If the query is changed as follows, the expected result is received: > SELECT * FROM ( > SELECT b.count, enterprise_id FROM ( > SELECT COUNT(*), 35 AS enterprise_id FROM ( > SELECT "A Name" AS Name, 37 AS enterprise_id > ) c GROUP BY enterprise_id > ) b > ) a WHERE enterprise_id = 1 OPTION DEBUG > Which yields a very similar plan: > PLAN TREE: > (type=Relational, command=SELECT * FROM (SELECT b."count", enterprise_id FROM (SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c GROUP BY enterprise_id) AS b) AS a WHERE enterprise_id = 1 OPTION DEBUG, props={0=PlanHints}) > canonical plan: > Project(groups=[b], props={90=[b."count", enterprise_id], 30=[b."count", enterprise_id], 114=0.0, 91=[A."COUNT", A.ENTERPRISE_ID]}) > Source(groups=[b], props={90=[b."count", enterprise_id], 64=SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c GROUP BY enterprise_id, 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}}) > Project(groups=[], props={90=[b."count", enterprise_id], 30=[COUNT(*), 35 AS enterprise_id], 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}, 91=[COUNT(*), 35 AS enterprise_id]}) > Group(groups=[c], props={90=[COUNT(*)], 114=0.0, 80=[enterprise_id], 81=[COUNT(*)]}) > Null(groups=[c], props={90=[enterprise_id], 114=0.0}) > PROCESSOR PLAN: > ProjectNode(1) output=[b."count", enterprise_id] [b."count", enterprise_id] > ProjectNode(2) output=[b."count", enterprise_id] [COUNT(*), 35 AS enterprise_id] > GroupingNode(3) output=[COUNT(*)] [enterprise_id] > NullNode(4) output=[enterprise_id] > Except the NullNode node contains enterprise_id as its target column vs an empty value. -- 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 [View Less]

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Moved: (TEIID-949) Criteria on constant column with aggregate function doesn't push criteria down correctly

by Steven Hawkins (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-949?page=com.atlassian.jira.plug... ] Steven Hawkins moved JBEDSP-1150 to TEIID-949: ---------------------------------------------- Project: Teiid (was: JBoss Enterprise Data Services Platform) Key: TEIID-949 (was: JBEDSP-1150) Component/s: Query Engine (was: Query) Affects Version/s: 7.0 (was: 5.5.4) > Criteria on constant column with aggregate … [View More]function doesn't push criteria down correctly > ---------------------------------------------------------------------------------------- > > Key: TEIID-949 > URL: https://jira.jboss.org/jira/browse/TEIID-949 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 7.0 > Environment: MM5.5.4 > Reporter: Larry O'Leary > Assignee: Larry O'Leary > > When a column value is a constant and used along with an aggregate, criteria on the constant column is being ignored. Here is an example query: > SELECT * FROM ( > SELECT b.count, enterprise_id FROM ( > SELECT COUNT(*), 35 AS enterprise_id FROM ( > SELECT "A Name" AS Name, 37 AS enterprise_id > ) c > ) b > ) a WHERE enterprise_id = 1 OPTION DEBUG > The expected result is an empty result set. Instead, the result set comes back as: > COUNT, ENTERPRISE_ID > 0, 35 > The resulting plan looks like: > OPTIMIZATION COMPLETE: > PLAN TREE: > (type=Relational, command=SELECT * FROM (SELECT b."count", enterprise_id FROM (SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c) AS b) AS a WHERE enterprise_id = 1 OPTION DEBUG, props={0=PlanHints}) > canonical plan: > Project(groups=[b], props={90=[b."count", enterprise_id], 30=[b."count", enterprise_id], 114=0.0, 91=[A."COUNT", A.ENTERPRISE_ID]}) > Source(groups=[b], props={90=[b."count", enterprise_id], 64=SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c, 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}}) > Project(groups=[], props={90=[b."count", enterprise_id], 30=[COUNT(*), 35 AS enterprise_id], 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}, 91=[COUNT(*), 35 AS enterprise_id]}) > Group(groups=[c], props={90=[COUNT(*)], 114=0.0, 81=[COUNT(*)]}) > Null(groups=[c], props={90=[], 114=0.0}) > PROCESSOR PLAN: > ProjectNode(1) output=[b."count", enterprise_id] [b."count", enterprise_id] > ProjectNode(2) output=[b."count", enterprise_id] [COUNT(*), 35 AS enterprise_id] > GroupingNode(3) output=[COUNT(*)] null > NullNode(4) output=[] > If the query is changed as follows, the expected result is received: > SELECT * FROM ( > SELECT b.count, enterprise_id FROM ( > SELECT COUNT(*), 35 AS enterprise_id FROM ( > SELECT "A Name" AS Name, 37 AS enterprise_id > ) c GROUP BY enterprise_id > ) b > ) a WHERE enterprise_id = 1 OPTION DEBUG > Which yields a very similar plan: > PLAN TREE: > (type=Relational, command=SELECT * FROM (SELECT b."count", enterprise_id FROM (SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c GROUP BY enterprise_id) AS b) AS a WHERE enterprise_id = 1 OPTION DEBUG, props={0=PlanHints}) > canonical plan: > Project(groups=[b], props={90=[b."count", enterprise_id], 30=[b."count", enterprise_id], 114=0.0, 91=[A."COUNT", A.ENTERPRISE_ID]}) > Source(groups=[b], props={90=[b."count", enterprise_id], 64=SELECT COUNT(*), 35 AS enterprise_id FROM (SELECT 'A Name' AS Name, 37 AS enterprise_id) AS c GROUP BY enterprise_id, 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}}) > Project(groups=[], props={90=[b."count", enterprise_id], 30=[COUNT(*), 35 AS enterprise_id], 114=0.0, 60={b."count"=COUNT(*), b.enterprise_id=35}, 91=[COUNT(*), 35 AS enterprise_id]}) > Group(groups=[c], props={90=[COUNT(*)], 114=0.0, 80=[enterprise_id], 81=[COUNT(*)]}) > Null(groups=[c], props={90=[enterprise_id], 114=0.0}) > PROCESSOR PLAN: > ProjectNode(1) output=[b."count", enterprise_id] [b."count", enterprise_id] > ProjectNode(2) output=[b."count", enterprise_id] [COUNT(*), 35 AS enterprise_id] > GroupingNode(3) output=[COUNT(*)] [enterprise_id] > NullNode(4) output=[enterprise_id] > Except the NullNode node contains enterprise_id as its target column vs an empty value. -- 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 [View Less]

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Commented: (TEIID-502) Allow Multiple UDF Definition Models

by Ramesh Reddy (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-502?page=com.atlassian.jira.plug... ] Ramesh Reddy commented on TEIID-502: ------------------------------------ By allowing the user to have a "FunctionDefinition.xml" per VDB this can be solved. However this removes support for the global "FunctionDefinitions.xmi". Also this aids to deploy the UDF module in single VDB artifact. User who are using the this UDF in global nature can get same features by adding this file to every VDB they are used in. … [View More]

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-502) Allow Multiple UDF Definition Models

by Ramesh Reddy (JIRA)

[ https://jira.jboss.org/jira/browse/TEIID-502?page=com.atlassian.jira.plug... ] Ramesh Reddy updated TEIID-502: ------------------------------- Parent: TEIID-833 Issue Type: Sub-task (was: Feature Request) > Allow Multiple UDF Definition Models > ------------------------------------ > > Key: TEIID-502 > URL: https://jira.jboss.org/jira/browse/TEIID-502 > Project: Teiid > Issue Type: Sub-task > … [View More]

15 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues February 2010