July 2019 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-5793) Upgrade commons-configuration to 1.7 to upgrade commons-beanutils

by Van Halbert (Jira)

[ https://issues.jboss.org/browse/TEIID-5793?page=com.atlassian.jira.plugin... ] Van Halbert updated TEIID-5793: ------------------------------- Git Pull Request: https://github.com/teiid/teiid/pull/1171 > Upgrade commons-configuration to 1.7 to upgrade commons-beanutils > ----------------------------------------------------------------- > > Key: TEIID-5793 > URL: https://issues.jboss.org/browse/TEIID-5793 > Project: Teiid > Issue Type: Quality Risk > Components: Build/Kits > Affects Versions: 12.3 > Reporter: Van Halbert > Assignee: Van Halbert > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5794) GENERATED_KEY function in an input trigger results in validation error if used in presence of a compound primary key which consists of a mix of auto-increment and non-auto-increment variables

by Christoph John (Jira)

[ https://issues.jboss.org/browse/TEIID-5794?page=com.atlassian.jira.plugin... ] Christoph John updated TEIID-5794: ---------------------------------- Summary: GENERATED_KEY function in an input trigger results in validation error if used in presence of a compound primary key which consists of a mix of auto-increment and non-auto-increment variables (was: GENERATED_KEY function results in validation error if used in presence of a compound primary key which consists of a mix of auto-increment and non-auto-increment properties) > GENERATED_KEY function in an input trigger results in validation error if used in presence of a compound primary key which consists of a mix of auto-increment and non-auto-increment variables > ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: TEIID-5794 > URL: https://issues.jboss.org/browse/TEIID-5794 > Project: Teiid > Issue Type: Bug > Affects Versions: 12.3 > Reporter: Christoph John > Assignee: Steven Hawkins > Priority: Blocker > > The issue refers to > https://issues.jboss.org/browse/TEIID-5782 where if was found, that > the GENERATED_KEY function does result in an validation error > validation error: TEIID31119 Symbol key.fkProduct is specified with an unknown group context > in an INSERT trigger when the view on which the insert is called has a compound primary key which consists of a mix of AUTO_INCREMENT and non-AUTO_INCREMENT variables. > A code example can be found in the following comment > https://issues.jboss.org/browse/TEIID-5782?focusedCommentId=13759345&page... -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5782) When overwriting an Insert trigger with custom logic in a ddl file, the primary key is not correctly transferred back in the response of the odata layer with a dummy insert value

by Christoph John (Jira)

[ https://issues.jboss.org/browse/TEIID-5782?page=com.atlassian.jira.plugin... ] Christoph John commented on TEIID-5782: --------------------------------------- Hello Steven, I have added the following issue: https://issues.jboss.org/browse/TEIID-5794 > When overwriting an Insert trigger with custom logic in a ddl file, the primary key is not correctly transferred back in the response of the odata layer with a dummy insert value > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: TEIID-5782 > URL: https://issues.jboss.org/browse/TEIID-5782 > Project: Teiid > Issue Type: Quality Risk > Components: OData > Affects Versions: 12.3 > Reporter: Christoph John > Assignee: Steven Hawkins > Priority: Major > > Hello, > in the past we had an issue in the odata layer, that the generated primary key of an autoincrement key was not corretly transfered back in the odata response. This issue was fixed. > However, the current issues derives from the discussion in > https://issues.jboss.org/browse/TEIID-5763 > where we havewritten an INSTEAD OF INSERT trigger. According to my last comment to https://issues.jboss.org/browse/TEIID-5763, there are two situations which can arrise. I have to set the 1. key group explicitely or 2. it is set implicitely. > Now in both situations I observe the same result. When I POST an INSERT with a dummy primary key, say key=0 (as it was NOT NULL in the past, and I am still using the old sources) I retrieve key=0 in the odata response. Correct would be to get a response with the generated key instead. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5794) GENERATED_KEY function results in validation error if used in presence of a compound primary key which consists of a mix of auto-increment and non-auto-increment properties

by Christoph John (Jira)

Christoph John created TEIID-5794: ------------------------------------- Summary: GENERATED_KEY function results in validation error if used in presence of a compound primary key which consists of a mix of auto-increment and non-auto-increment properties Key: TEIID-5794 URL: https://issues.jboss.org/browse/TEIID-5794 Project: Teiid Issue Type: Bug Affects Versions: 12.3 Reporter: Christoph John Assignee: Steven Hawkins The issue refers to https://issues.jboss.org/browse/TEIID-5782 where if was found, that the GENERATED_KEY function does result in an validation error validation error: TEIID31119 Symbol key.fkProduct is specified with an unknown group context in an INSERT trigger when the view on which the insert is called has a compound primary key which consists of a mix of AUTO_INCREMENT and non-AUTO_INCREMENT variables. A code example can be found in the following comment https://issues.jboss.org/browse/TEIID-5782?focusedCommentId=13759345&page... -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5782) When overwriting an Insert trigger with custom logic in a ddl file, the primary key is not correctly transferred back in the response of the odata layer with a dummy insert value

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5782?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5782: --------------------------------------- Yes, that should be covered by a new issue. Can you create one? > When overwriting an Insert trigger with custom logic in a ddl file, the primary key is not correctly transferred back in the response of the odata layer with a dummy insert value > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: TEIID-5782 > URL: https://issues.jboss.org/browse/TEIID-5782 > Project: Teiid > Issue Type: Quality Risk > Components: OData > Affects Versions: 12.3 > Reporter: Christoph John > Assignee: Steven Hawkins > Priority: Major > > Hello, > in the past we had an issue in the odata layer, that the generated primary key of an autoincrement key was not corretly transfered back in the odata response. This issue was fixed. > However, the current issues derives from the discussion in > https://issues.jboss.org/browse/TEIID-5763 > where we havewritten an INSTEAD OF INSERT trigger. According to my last comment to https://issues.jboss.org/browse/TEIID-5763, there are two situations which can arrise. I have to set the 1. key group explicitely or 2. it is set implicitely. > Now in both situations I observe the same result. When I POST an INSERT with a dummy primary key, say key=0 (as it was NOT NULL in the past, and I am still using the old sources) I retrieve key=0 in the odata response. Correct would be to get a response with the generated key instead. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5792) Permissions don't work with virtual procedures' ResultSet

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5792?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5792: --------------------------------------- > we should wrap the call in select to specify cols which we want to request Which is logically creating a view, thus the expectation of the suggested workaround in this case. > For views if we use "select *" and have restrictions on columns we will get error until we specify allowed columns. With the org.teiid.ignoreUnauthorizedAsterisk option, you can still use select * > Permissions don't work with virtual procedures' ResultSet > --------------------------------------------------------- > > Key: TEIID-5792 > URL: https://issues.jboss.org/browse/TEIID-5792 > Project: Teiid > Issue Type: Enhancement > Components: Query Engine > Affects Versions: 12.0 > Environment: teiid-12.0.0 on WildFly Full 14.0.1.Final (WildFly Core 6.0.2.Final) > Reporter: Dmitrii Pogorelov > Assignee: Steven Hawkins > Priority: Major > > Teiid doesn't work with ResultSet of a virtual procedure. For example, if we have procs.testProc virtual procedure which can return two values in ResultSet: a and b and we specify a permission for one of these columns in ResultSet, the permission won't work: > {code:xml} > <permission> > <resource-name>procs.testProc.a</resource-name> > <allow-read>false</allow-read> > </permission> > {code} > I think it would be great to set permissions also for ResultSets of virtual procedures, so AuthorizationValidationVisitor.validateEntitlements method for a GroupSymbol, which is a procedure, should analyze also its ResultSet. At the same time permissions work for virtual views and we can set permissions for some views' columns separately. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5792) Permissions don't work with virtual procedures' ResultSet

by Dmitrii Pogorelov (Jira)

[ https://issues.jboss.org/browse/TEIID-5792?page=com.atlassian.jira.plugin... ] Dmitrii Pogorelov commented on TEIID-5792: ------------------------------------------ [~shawkins] hm... If we set permissions for resultset of a procedure explicitly then we should specify requested columns. I mean if use the command: call proc(...) and set a permission for a resultset we should wrap the call in select to specify cols which we want to request. Otherwise we should return an error as it's done for views. For views if we use "select *" and have restrictions on columns we will get error until we specify allowed columns. The same approach should be used for procedures, we should throw out an error until client specify allowed result set. That is if user sets permissions for a procedure the user expects that client will request explicitly columns otherwise we should show error. > Permissions don't work with virtual procedures' ResultSet > --------------------------------------------------------- > > Key: TEIID-5792 > URL: https://issues.jboss.org/browse/TEIID-5792 > Project: Teiid > Issue Type: Enhancement > Components: Query Engine > Affects Versions: 12.0 > Environment: teiid-12.0.0 on WildFly Full 14.0.1.Final (WildFly Core 6.0.2.Final) > Reporter: Dmitrii Pogorelov > Assignee: Steven Hawkins > Priority: Major > > Teiid doesn't work with ResultSet of a virtual procedure. For example, if we have procs.testProc virtual procedure which can return two values in ResultSet: a and b and we specify a permission for one of these columns in ResultSet, the permission won't work: > {code:xml} > <permission> > <resource-name>procs.testProc.a</resource-name> > <allow-read>false</allow-read> > </permission> > {code} > I think it would be great to set permissions also for ResultSets of virtual procedures, so AuthorizationValidationVisitor.validateEntitlements method for a GroupSymbol, which is a procedure, should analyze also its ResultSet. At the same time permissions work for virtual views and we can set permissions for some views' columns separately. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5792) Permissions don't work with virtual procedures' ResultSet

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5792?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5792: --------------------------------------- The scope of this is actually larger. Suppose I directly issue: call proc(...) If there are columns that I'm not entitled to on the result set, that would error. Just like with select *, we'd have to also introduce resolving changes to omit those result set columns from being returned to the client. Then what if all result set columns are not accessible? Does the result set convey the row count and have no columns, or should it be completely empty. In short expecting the vdb developer to wrap things in a view clarifies this greatly. > Permissions don't work with virtual procedures' ResultSet > --------------------------------------------------------- > > Key: TEIID-5792 > URL: https://issues.jboss.org/browse/TEIID-5792 > Project: Teiid > Issue Type: Enhancement > Components: Query Engine > Affects Versions: 12.0 > Environment: teiid-12.0.0 on WildFly Full 14.0.1.Final (WildFly Core 6.0.2.Final) > Reporter: Dmitrii Pogorelov > Assignee: Steven Hawkins > Priority: Major > > Teiid doesn't work with ResultSet of a virtual procedure. For example, if we have procs.testProc virtual procedure which can return two values in ResultSet: a and b and we specify a permission for one of these columns in ResultSet, the permission won't work: > {code:xml} > <permission> > <resource-name>procs.testProc.a</resource-name> > <allow-read>false</allow-read> > </permission> > {code} > I think it would be great to set permissions also for ResultSets of virtual procedures, so AuthorizationValidationVisitor.validateEntitlements method for a GroupSymbol, which is a procedure, should analyze also its ResultSet. At the same time permissions work for virtual views and we can set permissions for some views' columns separately. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5793) Upgrade commons-configuration to 1.7 to upgrade commons-beanutils

by Van Halbert (Jira)

Van Halbert created TEIID-5793: ---------------------------------- Summary: Upgrade commons-configuration to 1.7 to upgrade commons-beanutils Key: TEIID-5793 URL: https://issues.jboss.org/browse/TEIID-5793 Project: Teiid Issue Type: Quality Risk Components: Build/Kits Affects Versions: 12.3 Reporter: Van Halbert Assignee: Van Halbert -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5792) Permissions don't work with virtual procedures' ResultSet

by Dmitrii Pogorelov (Jira)

[ https://issues.jboss.org/browse/TEIID-5792?page=com.atlassian.jira.plugin... ] Dmitrii Pogorelov commented on TEIID-5792: ------------------------------------------ [~shawkins] well, I would say it's not good idea to wrap procedures in views to get permissions worked. As a urgent workaround it's ok but not like a constant solution. Especially if it takes 2 hrs to solve the issue. If you add the additional logic for procedures in the authorization logic we will get really the consistent behavior. In short I would lobby the issue for its inclusion :) > Permissions don't work with virtual procedures' ResultSet > --------------------------------------------------------- > > Key: TEIID-5792 > URL: https://issues.jboss.org/browse/TEIID-5792 > Project: Teiid > Issue Type: Enhancement > Components: Query Engine > Affects Versions: 12.0 > Environment: teiid-12.0.0 on WildFly Full 14.0.1.Final (WildFly Core 6.0.2.Final) > Reporter: Dmitrii Pogorelov > Assignee: Steven Hawkins > Priority: Major > > Teiid doesn't work with ResultSet of a virtual procedure. For example, if we have procs.testProc virtual procedure which can return two values in ResultSet: a and b and we specify a permission for one of these columns in ResultSet, the permission won't work: > {code:xml} > <permission> > <resource-name>procs.testProc.a</resource-name> > <allow-read>false</allow-read> > </permission> > {code} > I think it would be great to set permissions also for ResultSets of virtual procedures, so AuthorizationValidationVisitor.validateEntitlements method for a GroupSymbol, which is a procedure, should analyze also its ResultSet. At the same time permissions work for virtual views and we can set permissions for some views' columns separately. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 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 2019