May 2013 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-2509) Attempt to create second salesforce source fails

by Mark Drilling (JIRA)

[ https://issues.jboss.org/browse/TEIID-2509?page=com.atlassian.jira.plugin... ] Mark Drilling updated TEIID-2509: --------------------------------- Attachment: Exception_duplicateSF.txt > Attempt to create second salesforce source fails > ------------------------------------------------ > > Key: TEIID-2509 > URL: https://issues.jboss.org/browse/TEIID-2509 > Project: Teiid > Issue Type: Bug > Components: AdminApi > Affects Versions: 8.4 > Environment: Fedora 17, Teiid 8.4 Beta2, JBoss EAP 6.1 alpha > Reporter: Mark Drilling > Assignee: Steven Hawkins > Attachments: Exception_duplicateSF.txt > > > Attempt to create a second salesforce datasource via the Admin api fails (stacktrace attached). When I restart the server, it appears. > I tried the same scenario with the Twitter WS example and it worked - did not need to restart server. -- 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

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2508) Admin api getSchema fails for long schema

by Mark Drilling (JIRA)

Mark Drilling created TEIID-2508: ------------------------------------ Summary: Admin api getSchema fails for long schema Key: TEIID-2508 URL: https://issues.jboss.org/browse/TEIID-2508 Project: Teiid Issue Type: Bug Components: AdminApi Affects Versions: 8.4 Environment: Fedora 17, Teiid 8.4 Beta2, JBoss EAP 6.1 alpha Reporter: Mark Drilling Assignee: Steven Hawkins Attachments: Exception_getDDL.txt The admin.getSchema call to return DDL is failing for long schema (no problem with just a few tables). We had a different issue previously but this is still an issue with 8.4B2 in EAP6.1Alpha. Attaching server stacktrace. -- 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

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2508) Admin api getSchema fails for long schema

by Mark Drilling (JIRA)

[ https://issues.jboss.org/browse/TEIID-2508?page=com.atlassian.jira.plugin... ] Mark Drilling updated TEIID-2508: --------------------------------- Attachment: Exception_getDDL.txt > Admin api getSchema fails for long schema > ----------------------------------------- > > Key: TEIID-2508 > URL: https://issues.jboss.org/browse/TEIID-2508 > Project: Teiid > Issue Type: Bug > Components: AdminApi > Affects Versions: 8.4 > Environment: Fedora 17, Teiid 8.4 Beta2, JBoss EAP 6.1 alpha > Reporter: Mark Drilling > Assignee: Steven Hawkins > Attachments: Exception_getDDL.txt > > > The admin.getSchema call to return DDL is failing for long schema (no problem with just a few tables). We had a different issue previously but this is still an issue with 8.4B2 in EAP6.1Alpha. Attaching server stacktrace. -- 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

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2311) Add simple row based security to data roles

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2311?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2311: --------------------------------------- Added an explicit flag to disable the usage of a condition as an update constraint for 8.4: <condition constraint="false">COLUMNA=user()</condition> When false, the condition will no longer be checked as a constraint on the physical update (constraints are not enforced yet on virtual updates). > Add simple row based security to data roles > ------------------------------------------- > > Key: TEIID-2311 > URL: https://issues.jboss.org/browse/TEIID-2311 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 8.2 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.3 > > > A common request is to implement row based security. The common workaround of modifying transformations is generally not a good solution. > We should look at adding support for simple table filters and column masks. > To be effective, filtering permissions however would have to act differently than normal data roles. They would need to be applied all the time - and not just against the end user queries. > For example, for tables: > <permission> > <resource-name>SCHEMA.TABLE</resource-name> > <filter>COLUMNA=2</filter> > </permission> > Meaning allow the CRUD of the given row only if COLUMNA has the value of 2. Any valid predicate against just the referenced table would be allowed as a filter. Each such permission would be applied as an additional predicate any time the table is referenced (in views, inserts, updates, deletes, etc.). > Allows would not be specified here as we want the filter to always specify inclusion. Any applicable permissions in additional roles would be applied disjunctively - filter OR filter. > We could possibly support column masks via case expressions, such as: > <permission> > <resource-name>SCHEMA.TABLE.COLUMN</resource-name> > <mask>CASE WHEN ...</mask> > </permission> > However this is slightly more complicated. Presumably the mask would only apply to projection and makes more sense to be applied at the final output/user query (more like a data role). > If we work the issue to specify the object type of a permission, then the name could alternatively refer to datatype or even an extension property to make the masking a little easier. -- 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

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2471) Allow permission conditions and masking to be pluggable

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2471?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2471: --------------------------------------- There are a couple of considerations/paths to choose from here: 1. introduce an interface similar to the AuthorizationValidator/PolicyDecider to provide runtime control 2. allow the dataroles to in part or in whole be read in / updated through the metadata repository or other metadata extension. Unlike the authorization validation, which is performed only at the user query level and can easily be validated with each query access, the row/column logic is applied deeper in planning. Validating would require the interface to indicate if any row/column filter/mask had changed since the plan was formed and/or widen the EventDistributor logic to include a policy change event. There is also the related performance concern of caching the resolved/validate language object form of the respective expressions, which is hard to generalize for an interface. I'm more inclined to go with the latter approach and work out any details of on-demand modifications to the policy later. However the plugablity of metadata repositories doesn't match the declaration of data roles - which are vdb scoped. We may want to introduce another vdb extension point for pluggable role metadata. > Allow permission conditions and masking to be pluggable > ------------------------------------------------------- > > Key: TEIID-2471 > URL: https://issues.jboss.org/browse/TEIID-2471 > Project: Teiid > Issue Type: Sub-task > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.4 > > > The AuthorizationValidator or similar interface should allow for alternative implementations to be plugged in for providing permission conditions and column masking. -- 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

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2361) The current MAX String size is 4000, add the ability to configure when larger sizes are used

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-2361?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-2361: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=896305, https://bugzilla.redhat.com/show_bug.cgi?id=964283 (was: https://bugzilla.redhat.com/show_bug.cgi?id=896305) > The current MAX String size is 4000, add the ability to configure when larger sizes are used > -------------------------------------------------------------------------------------------- > > Key: TEIID-2361 > URL: https://issues.jboss.org/browse/TEIID-2361 > Project: Teiid > Issue Type: Enhancement > Components: Query Engine > Reporter: Van Halbert > Assignee: Steven Hawkins > Fix For: 8.3 > > > The MAX String size is currently 4000. After a discussion with Steve, he indicated a more common default might be 16k, and also add the ability to configure the size when a data source is being used that contains large sizes. -- 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

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2506) Additional row based security issues

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2506?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-2506. ----------------------------------- Resolution: Done Resolved as part of a larger refinement of the security feature. Ensured that filters are always applied appropriately and that values outside of an update are properly accounted for in the compensating procedure so that they do not inhibit the update. > Additional row based security issues > ------------------------------------ > > Key: TEIID-2506 > URL: https://issues.jboss.org/browse/TEIID-2506 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.3 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Critical > Fix For: 8.4 > > > On updates, constraints with values outside of the changelist will throw an exception. Also, non-compensated updates should always have the condition applied as a row filter - which currently it is not. -- 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

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2507) Better handling of user scoped lookups

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-2507: ------------------------------------- Summary: Better handling of user scoped lookups Key: TEIID-2507 URL: https://issues.jboss.org/browse/TEIID-2507 Project: Teiid Issue Type: Quality Risk Components: Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 8.4 With the inclusion of column and row security logic, it's more likely that lookups can produce user specific results. The current logic however treats lookups as always globally scoped. -- 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

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2506) Additional row based security issues

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-2506: ------------------------------------- Summary: Additional row based security issues Key: TEIID-2506 URL: https://issues.jboss.org/browse/TEIID-2506 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 8.3 Reporter: Steven Hawkins Assignee: Steven Hawkins Priority: Critical Fix For: 8.4 On updates, constraints with values outside of the changelist will throw an exception. Also, non-compensated updates should always have the condition applied as a row filter - which currently it is not. -- 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

12 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2502) org.teiid.net.socket.SingleInstanceCommunicationException

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2502?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2502: --------------------------------------- > So maybe a struct could be better than object? Is something that can be tried on my part or a patch yuo need to address? More than likely ResultSet.getObject is returning an Oracle STRUCT - however their STRUCT is not fully serializable as it has the connection as a member. There are a couple of options: - Use the STRUCT.getAttributes method to map the value to an Object[] (which presumably would be serializable). A variant of this would be to use a SerialStruct to do effectively the same thing. These would not be specific to Oracle. - Use the JGeometry representation. Either way built-in handling will require some thought (how to formalize struct handling and/or the best approach to spatial support), but my initial thought would likely be to use the SerialStruct approach. The quickest fix would be to extend the OracleExecutionFactory and add whatever handling you want in overriden retrieveValue methods. > org.teiid.net.socket.SingleInstanceCommunicationException > --------------------------------------------------------- > > Key: TEIID-2502 > URL: https://issues.jboss.org/browse/TEIID-2502 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.2 > Environment: centos 6.3 > Reporter: luca gioppo > Assignee: Steven Hawkins > Priority: Critical > > I'm issuing a query (a simple select * from table) on a VDB's table that contains a geometric column from oracle spatial. > I'm getting the following error in SquirrelSQL > Error: org.teiid.net.socket.SingleInstanceCommunicationException > SQLState: 08S01 > ErrorCode: 0 > Afterwards the connection is broken and I cannot access any other table and have to reconnect since I get: > Error: Error Code:TEIID20013 Message:Error Code:TEIID20013 Message:java.net.SocketException: Socket closed > SQLState: TEIID20013 > ErrorCode: 0 > I'm trying to access a SDO table and a geometry type column, but hoped that TEIID could read it as a BLOB without caring about the real type. > Probably it doesn't like it too much. -- 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

12 years, 10 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 May 2013