July 2013 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-2567) issues with permission element in vdb-deployer.xsd contains problematic choice node

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2567?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2567: --------------------------------------- > what is drawback in having the "allows-language" with other allows? It is just scope issue that it needs to defined at permission level? The drawback is just a clarity issue. Grouping the allows by object type is a generally a good idea. > 1) If you don't foresee any more "choices" or resource types for permissions, then I'd vote for attributes. We will add more types and allows as needed. > 2) If you do think you'll add more choices, then I'd convert the <sequence> to a named type and I'm pretty sure JAXB could handle it. Are you implying then that you are not in favor of just putting all of the allow elements under the same sequence and/or can you provide an example of what you mean? > issues with permission element in vdb-deployer.xsd contains problematic choice node > ----------------------------------------------------------------------------------- > > Key: TEIID-2567 > URL: https://issues.jboss.org/browse/TEIID-2567 > Project: Teiid > Issue Type: Task > Affects Versions: 8.4 > Reporter: Barry LaFond > Assignee: Steven Hawkins > Fix For: 8.4.1 > > > Having a lot of trouble trying to tweak our JaxB VDB element classes to accommodate the permission's choice node which contains a <sequence> and an <element>. > This structure is basically impossible to unmarshall using JAXB annotations (i.e. @XmlElements(value= {}) ) > Would clean things up to convert the <allow-language> element to an attribute: <xs:attribute name="allow-language" type="xs:boolean"/> and place it on the <permission> element AND remove the <choice> node entirely -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2571) Generally allow must pushdown function evaluation

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2571?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-2571. ----------------------------------- Resolution: Done Added an initial implementation that is a simple / late evaluation of must pushdown functions tied to a schema one at a time. If this feature gets more use, then we'll want to address: - multi-source support to select a single source to execute the function against - grouping function calls together TEIID-1131 now has a clearer implementation path as imported sequence functions will function as expected as must pushdown functions > Generally allow must pushdown function evaluation > ------------------------------------------------- > > Key: TEIID-2571 > URL: https://issues.jboss.org/browse/TEIID-2571 > Project: Teiid > Issue Type: Enhancement > Components: Connector API, Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.5 > > > A must pushdown function not associated with an access node will fail to evaluate. We can initially improve upon this with translator that support "select without from" to issue a scalar select of the value. > We can also enhance planning to group all such accesses to prevent multiple calls and to determine a possible source target if the function is not associated with a source schema. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2567) issues with permission element in vdb-deployer.xsd contains problematic choice node

by Barry LaFond (JIRA)

[ https://issues.jboss.org/browse/TEIID-2567?page=com.atlassian.jira.plugin... ] Barry LaFond commented on TEIID-2567: ------------------------------------- >From the <permission> element standpoint there is still a choice of which resource type the permission is applied to: table/column or "language". So changing all allows to attributes would cloud the issue a bit if just looking at the schema, but Designer could still handle it in our business logic. 1) If you don't foresee any more "choices" or resource types for permissions, then I'd vote for attributes. 2) If you do think you'll add more choices, then I'd convert the <sequence> to a named type and I'm pretty sure JAXB could handle it. > issues with permission element in vdb-deployer.xsd contains problematic choice node > ----------------------------------------------------------------------------------- > > Key: TEIID-2567 > URL: https://issues.jboss.org/browse/TEIID-2567 > Project: Teiid > Issue Type: Task > Affects Versions: 8.4 > Reporter: Barry LaFond > Assignee: Steven Hawkins > Fix For: 8.4.1 > > > Having a lot of trouble trying to tweak our JaxB VDB element classes to accommodate the permission's choice node which contains a <sequence> and an <element>. > This structure is basically impossible to unmarshall using JAXB annotations (i.e. @XmlElements(value= {}) ) > Would clean things up to convert the <allow-language> element to an attribute: <xs:attribute name="allow-language" type="xs:boolean"/> and place it on the <permission> element AND remove the <choice> node entirely -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2567) issues with permission element in vdb-deployer.xsd contains problematic choice node

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-2567?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-2567: ------------------------------------- what is drawback in having the "allows-language" with other allows? It is just scope issue that it needs to defined at permission level? > issues with permission element in vdb-deployer.xsd contains problematic choice node > ----------------------------------------------------------------------------------- > > Key: TEIID-2567 > URL: https://issues.jboss.org/browse/TEIID-2567 > Project: Teiid > Issue Type: Task > Affects Versions: 8.4 > Reporter: Barry LaFond > Assignee: Steven Hawkins > Fix For: 8.4.1 > > > Having a lot of trouble trying to tweak our JaxB VDB element classes to accommodate the permission's choice node which contains a <sequence> and an <element>. > This structure is basically impossible to unmarshall using JAXB annotations (i.e. @XmlElements(value= {}) ) > Would clean things up to convert the <allow-language> element to an attribute: <xs:attribute name="allow-language" type="xs:boolean"/> and place it on the <permission> element AND remove the <choice> node entirely -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2567) issues with permission element in vdb-deployer.xsd contains problematic choice node

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2567?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2567: --------------------------------------- So to sum up if a change is needed, we can either convert all of the allows to attributes (and possibly shorten their names) or the least amount of effort is to just remove the choice and put allows-language with the rest of the allows. Does anyone else want to weigh in? > issues with permission element in vdb-deployer.xsd contains problematic choice node > ----------------------------------------------------------------------------------- > > Key: TEIID-2567 > URL: https://issues.jboss.org/browse/TEIID-2567 > Project: Teiid > Issue Type: Task > Affects Versions: 8.4 > Reporter: Barry LaFond > Assignee: Steven Hawkins > Fix For: 8.4.1 > > > Having a lot of trouble trying to tweak our JaxB VDB element classes to accommodate the permission's choice node which contains a <sequence> and an <element>. > This structure is basically impossible to unmarshall using JAXB annotations (i.e. @XmlElements(value= {}) ) > Would clean things up to convert the <allow-language> element to an attribute: <xs:attribute name="allow-language" type="xs:boolean"/> and place it on the <permission> element AND remove the <choice> node entirely -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2570) blocked code lookup needs to consider key value

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2570?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-2570. ----------------------------------- Resolution: Done added the key value to the saved key > blocked code lookup needs to consider key value > ----------------------------------------------- > > Key: TEIID-2570 > URL: https://issues.jboss.org/browse/TEIID-2570 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.4 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.4.1, 8.5 > > > TEIID-2507 allowed lookups to block but introduced an issue. In rare circumstances, such as accessing a code table for the first time from two branches of a union such that a lookup of one value is performed in the first branch and a lookup of another value is performed in the second branch, the same value could be returned for each. Subsequent lookups would not exhibit the same behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2571) Generally allow must pushdown function evaluation

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-2571: ------------------------------------- Summary: Generally allow must pushdown function evaluation Key: TEIID-2571 URL: https://issues.jboss.org/browse/TEIID-2571 Project: Teiid Issue Type: Enhancement Components: Connector API, Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 8.5 A must pushdown function not associated with an access node will fail to evaluate. We can initially improve upon this with translator that support "select without from" to issue a scalar select of the value. We can also enhance planning to group all such accesses to prevent multiple calls and to determine a possible source target if the function is not associated with a source schema. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2570) blocked code lookup needs to consider key value

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-2570: ------------------------------------- Summary: blocked code lookup needs to consider key value Key: TEIID-2570 URL: https://issues.jboss.org/browse/TEIID-2570 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 8.4 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 8.4.1, 8.5 TEIID-2507 allowed lookups to block but introduced an issue. In rare circumstances, such as accessing a code table for the first time from two branches of a union such that a lookup of one value is performed in the first branch and a lookup of another value is performed in the second branch, the same value could be returned for each. Subsequent lookups would not exhibit the same behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2569) Inefficient Outer Join compensation when translator restricted on KEY based joins

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-2569?page=com.atlassian.jira.plugin... ] Ramesh Reddy edited comment on TEIID-2569 at 7/3/13 5:42 PM: ------------------------------------------------------------- This is the correct one, when inner joins were taken out {code} SELECT G1.e1, G2.e1, G3.e1 FROM G1 LEFT OUTER JOIN G2 ON G1.e1 = G2.e2 LEFT OUTER JOIN G3 ON G2.e2 = G3.e3 WHERE G2.e2 IS NOT NULL AND G3.e3 IS NOT NULL {code} was (Author: rareddy): Yes, this is the correct one, when inner joins were taken out {code} SELECT G1.e1, G2.e1, G3.e1 FROM G1 LEFT OUTER JOIN G2 ON G1.e1 = G2.e2 LEFT OUTER JOIN G3 ON G2.e2 = G3.e3 WHERE G2.e2 IS NOT NULL AND G3.e3 IS NOT NULL {code} > Inefficient Outer Join compensation when translator restricted on KEY based joins > --------------------------------------------------------------------------------- > > Key: TEIID-2569 > URL: https://issues.jboss.org/browse/TEIID-2569 > Project: Teiid > Issue Type: Enhancement > Components: Query Engine > Reporter: Ramesh Reddy > Assignee: Steven Hawkins > > When the following capabilities are set on ExecutionFactory > {code} > setSupportsOuterJoins(true); > setSupportedJoinCriteria(SupportedJoinCriteria.KEY); > {code} > A three table JOIN like > {code} > select G1.e1, G2.e1, G3.e1 from G1, G2, G3 where G1.e1=G2.e2 and G2.e2 = G3.e3 > {code} > gets pushed to translator as two separate queries like > {code} > SELECT G3.e3 AS c_0, G3.e1 AS c_1 FROM G3 ORDER BY c_0 > SELECT G2.e2 AS c_0, G1.e1 AS c_1, G2.e1 AS c_2 FROM G1 LEFT OUTER JOIN G2 ON G1.e1 = G2.e2 WHERE G2.e2 IS NOT NULL ORDER BY c_0 > {code} > instead of of one query which should be like > {code} > SELECT G1.e1, G2.e1, G3.e1 FROM G1 INNER JOIN G2 ON G1.e1 = G2.e2 INNER JOIN G3 ON G2.e2 = G3.e3 > {code} > When the key restriction is removed, it works fine, which should be un-related. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2569) Inefficient Outer Join compensation when translator restricted on KEY based joins

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-2569?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-2569: ------------------------------------- Yes, this is the correct one, when inner joins were taken out {code} SELECT G1.e1, G2.e1, G3.e1 FROM G1 LEFT OUTER JOIN G2 ON G1.e1 = G2.e2 LEFT OUTER JOIN G3 ON G2.e2 = G3.e3 WHERE G2.e2 IS NOT NULL AND G3.e3 IS NOT NULL {code} > Inefficient Outer Join compensation when translator restricted on KEY based joins > --------------------------------------------------------------------------------- > > Key: TEIID-2569 > URL: https://issues.jboss.org/browse/TEIID-2569 > Project: Teiid > Issue Type: Enhancement > Components: Query Engine > Reporter: Ramesh Reddy > Assignee: Steven Hawkins > > When the following capabilities are set on ExecutionFactory > {code} > setSupportsOuterJoins(true); > setSupportedJoinCriteria(SupportedJoinCriteria.KEY); > {code} > A three table JOIN like > {code} > select G1.e1, G2.e1, G3.e1 from G1, G2, G3 where G1.e1=G2.e2 and G2.e2 = G3.e3 > {code} > gets pushed to translator as two separate queries like > {code} > SELECT G3.e3 AS c_0, G3.e1 AS c_1 FROM G3 ORDER BY c_0 > SELECT G2.e2 AS c_0, G1.e1 AS c_1, G2.e1 AS c_2 FROM G1 LEFT OUTER JOIN G2 ON G1.e1 = G2.e2 WHERE G2.e2 IS NOT NULL ORDER BY c_0 > {code} > instead of of one query which should be like > {code} > SELECT G1.e1, G2.e1, G3.e1 FROM G1 INNER JOIN G2 ON G1.e1 = G2.e2 INNER JOIN G3 ON G2.e2 = G3.e3 > {code} > When the key restriction is removed, it works fine, which should be un-related. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues July 2013