January 2011 - teiid-issues - Jboss List Archives

[JBoss JIRA] Commented: (TEIID-43) command deterministic subqueries without from clauses should be merged if possible

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-43?page=com.atlassian.jira.plugin.s... ] Steven Hawkins commented on TEIID-43: ------------------------------------- The original customer issue I believe was around using views that were defined as a select without a from were inhibiting pushdown. That will no longer happen as an uncorrelated scalar subqueries, since they are eligible for evalaution prior to pushdown. Introducing a broad fix to enhance the usage of a select without a from as an inline view in a join does not seem necessary. There will only be an issue if that join is below a higher level outer join, and thus can't be rearranged properly for pushdown. One fix would be to allow ruleraiseaccess to see if a join child without a model can support the source/project nodes so that the access node can be raised (specific to select without a from). Another fix (which doesn't preclude the first) would be to do more analysis to group joins under outer joins more appropriately based upon the join criteria used. > command deterministic subqueries without from clauses should be merged if possible > ---------------------------------------------------------------------------------- > > Key: TEIID-43 > URL: https://issues.jboss.org/browse/TEIID-43 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Priority: Optional > Fix For: 7.4 > > > Defect Tracker #24752: command deterministic subqueries without from clauses should be merged if possible: > i.e. select e1, a from pm1.g1, (select 1 a) x <=> select e1, 1 from pm1.g1 > i.e. select e1, (select 1 a) from pm1.g1 <=> select e1, 1 from pm1.g1 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-146) Translate Criteria enhancement

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-146?page=com.atlassian.jira.plugin.... ] Steven Hawkins resolved TEIID-146. ---------------------------------- Fix Version/s: 7.3 (was: 8.0) Resolution: Won't Fix As of 7.2 the translate criteria logic was deprecated. Users should instead use a FOR EACH ROW procedure. > Translate Criteria enhancement > ------------------------------ > > Key: TEIID-146 > URL: https://issues.jboss.org/browse/TEIID-146 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 8.x > Reporter: Li Liang > Priority: Optional > Fix For: 7.3 > > > This is related to case 6658. There are limitations when using Translate Criteria: > 1. Alias is not handled. > 2. If the following query is used to define select query, although a.c and b.c are equivalent, use Translate Criteria on b does not work. > select a.c from a, b where a.c=b.c -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-373) MMx Audit logs may contain extremely long lines that are essentially unviewable

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-373?page=com.atlassian.jira.plugin.... ] Steven Hawkins resolved TEIID-373. ---------------------------------- Fix Version/s: (was: 8.x) Resolution: Out of Date The object editor logic no longer exists and we are not explicitly tracking configuration changes with audit support. In many instances we expect configuration values to be changed through direct edits to the teiid beans xml. > MMx Audit logs may contain extremely long lines that are essentially unviewable > ------------------------------------------------------------------------------- > > Key: TEIID-373 > URL: https://issues.jboss.org/browse/TEIID-373 > Project: Teiid > Issue Type: Task > Components: Embedded, Server > Affects Versions: 6.0.0 > Environment: Linux > Reporter: Paul Nittel > Priority: Minor > Attachments: MyAudit.zip > > > I'm attaching an example of an audit log that has a really long line that, maybe, has carriage returns without linefeeds. Regardless, the resulting file is illegible by Linux text editors. I tried with gedit and the text editor in Eclipse. Neither could display the file in reasonable fashion. > Windows fares better, but it's no picnic. > The contents of the audit log are from setting up a data role for reading the tables in MMR. 2.2MB as a result! -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-43) command deterministic subqueries without from clauses should be merged if possible

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-43?page=com.atlassian.jira.plugin.s... ] Steven Hawkins updated TEIID-43: -------------------------------- Fix Version/s: 7.4 (was: 8.x) Affects Version/s: 6.0.0 (was: 8.x) > command deterministic subqueries without from clauses should be merged if possible > ---------------------------------------------------------------------------------- > > Key: TEIID-43 > URL: https://issues.jboss.org/browse/TEIID-43 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Steven Hawkins > Priority: Optional > Fix For: 7.4 > > > Defect Tracker #24752: command deterministic subqueries without from clauses should be merged if possible: > i.e. select e1, a from pm1.g1, (select 1 a) x <=> select e1, 1 from pm1.g1 > i.e. select e1, (select 1 a) from pm1.g1 <=> select e1, 1 from pm1.g1 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-68) Equivalence expressions in where clauses between two columns are ignored.

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-68?page=com.atlassian.jira.plugin.s... ] Steven Hawkins resolved TEIID-68. --------------------------------- Fix Version/s: (was: 8.x) Resolution: Out of Date The old xml connector no longer exists. > Equivalence expressions in where clauses between two columns are ignored. > ------------------------------------------------------------------------- > > Key: TEIID-68 > URL: https://issues.jboss.org/browse/TEIID-68 > Project: Teiid > Issue Type: Bug > Components: XML Connector > Affects Versions: 8.x > Reporter: Steven Hawkins > Priority: Optional > > Defect Tracker #18728: If the where clause processed by the XML connectors has an equivalence expression containing two columns (where col1 = col2), the expression will be ignored. If the expression contains a column and a literal, it works properly. Thus a workaround is to use a scalar conversion function to convert the column to a literal. Something like substring(col1, 0) for string values or (col1 * 1) for numeric values. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Issue Comment Edited: (TEIID-952) Column level security capabilities

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-952?page=com.atlassian.jira.plugin.... ] Steven Hawkins edited comment on TEIID-952 at 1/25/11 2:04 PM: --------------------------------------------------------------- Marking as rejected unless an implementation proposal and compelling use case are provided. In any case, this has a limited scope - only user level SELECT * queries, which are typically avoided by application logic. There has also never been clarity on how this should work. Past proposals if someone issues a SELECT * query against a table containing a read protected value: 1. return empty data. However there is no clear indication to the user that his data has been altered. The vdb designer could also manually implement this approach by adding a view with a definition along the lines of "SELECT CASE WHEN HASROLE('foo') THEN protectedCol END, otherCol, ..." - null will be returned if the user does not have the given role. 2. to remove un-privileged columns in SELECT *, but leave the metadata as is. This is the most straight-forward, but I can't find any precedent for this behavior and it is logically inconsistent with the reported metadata. 3. change the metadata (as reported by the system tables and in resultset metadata, etc.) to remove un-privileged columns and remove hidden columns from top level SELECT * queries. This is only clearly correct if the user lacks all permissions against the column (select/insert/update). with mixed permissions it's unclear if the column should be hidden. This also introduces complications with the system table logic that assumes we can create cached forms of the odbc metadata - since the data is not specific to a given user. The workaround is also quite simple, just remove the offending column(s) by entering the full SELECT clause. was (Author: shawkins): Marking as rejected unless an implementation proposal and compelling use case are provided. In any case, this has a limited scope - only user level SELECT * queries, which are typically avoided by application logic. There has also never been clarity on how this should work. Past proposals if someone issues a SELECT * query against a table containing a read protected value: 1. return empty data. However there is no clear indication to the user that his data has been altered. 2. to remove un-privileged columns in SELECT *, but leave the metadata as is. This is the most straight-forward, but I can't find any precedent for this behavior and it is logically inconsistent with the reported metadata. 3. change the metadata (as reported by the system tables and in resultset metadata, etc.) to remove un-privileged columns and remove hidden columns from top level SELECT * queries. This is only clearly correct if the user lacks all permissions against the column (select/insert/update). with mixed permissions it's unclear if the column should be hidden. This also introduces complications with the system table logic that assumes we can create cached forms of the odbc metadata - since the data is not specific to a given user. The workaround is also quite simple, just remove the offending column(s) by entering the full SELECT clause. > Column level security capabilities > ---------------------------------- > > Key: TEIID-952 > URL: https://issues.jboss.org/browse/TEIID-952 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Reporter: Marc Shirley > Labels: security > > Request for the ability to enforce column level security as in the following example. This would be on the top most surface level affecting only the clients visibility to the columns. > User has access to col1, col2, and col3 out of a 6 column table. When a "SELECT *" is performed against the table, only those columns the user has access to are returned (col1, col2, and col3). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-229) Support update of the view column using a column

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-229?page=com.atlassian.jira.plugin.... ] Steven Hawkins resolved TEIID-229. ---------------------------------- Assignee: Steven Hawkins Fix Version/s: 7.3 (was: 8.x) Resolution: Done Resolved by adding the FOR EACH ROW update procedure handling. > Support update of the view column using a column > ------------------------------------------------ > > Key: TEIID-229 > URL: https://issues.jboss.org/browse/TEIID-229 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Affects Versions: 6.0.0 > Reporter: Li Liang > Assignee: Steven Hawkins > Fix For: 7.3 > > > This is related to case 176903. We do not support the update of a view column using a column instead of a constant (or expression that can be evaluated to a constant). e.g. update view1 set c1=c2. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-978) Ability to define the 'allowed' values for a type via a defined query. (also relevant to descriptions as well)

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-978?page=com.atlassian.jira.plugin.... ] Steven Hawkins resolved TEIID-978. ---------------------------------- Resolution: Incomplete Description Marking as incomplete until more detail is provided. > Ability to define the 'allowed' values for a type via a defined query. (also relevant to descriptions as well) > -------------------------------------------------------------------------------------------------------------- > > Key: TEIID-978 > URL: https://issues.jboss.org/browse/TEIID-978 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Reporter: Marc Shirley > -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Resolved: (TEIID-1093) Request addition of ODC file connections

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-1093?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-1093. ----------------------------------- Resolution: Incomplete Description Marking as incomplete since additional information has not been provided. > Request addition of ODC file connections > ---------------------------------------- > > Key: TEIID-1093 > URL: https://issues.jboss.org/browse/TEIID-1093 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Reporter: Debbie Steigner > > Customer is requesting to include a standard connection to work with MicroSoft "Office Data Connection"(ODC)files -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (TEIID-1096) Allow cost analysis tool to work against custom connectors

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-1096?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-1096: ---------------------------------- Fix Version/s: 7.4 Priority: Minor (was: Optional) We'll see if we can get this as part of runtime costing in 7.4. However this would only affect Teiid. The original ticket was probably geared more toward Designer. > Allow cost analysis tool to work against custom connectors > ---------------------------------------------------------- > > Key: TEIID-1096 > URL: https://issues.jboss.org/browse/TEIID-1096 > Project: Teiid > Issue Type: Feature Request > Components: Jopr Plugin, Server > Reporter: Marc Shirley > Priority: Minor > Fix For: 7.4 > > > case 5541 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 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 January 2011