June 2015 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-3408) Update the quickstarts that refer to using user .properties files and user roles files

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3408?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3408: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1190678|https://bugzilla.redhat.com/show_bug.cgi?id=1190678] from ASSIGNED to MODIFIED > Update the quickstarts that refer to using user .properties files and user roles files > -------------------------------------------------------------------------------------- > > Key: TEIID-3408 > URL: https://issues.jboss.org/browse/TEIID-3408 > Project: Teiid > Issue Type: Bug > Components: Quick Starts > Reporter: Van Halbert > Assignee: Van Halbert > Priority: Minor > > Update the quoickstarts that still refer to using user security .properties and user roles files. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3410) OData object URI does not resolve to a usable URL.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3410?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3410: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1208515|https://bugzilla.redhat.com/show_bug.cgi?id=1208515] from ASSIGNED to MODIFIED > OData object URI does not resolve to a usable URL. > -------------------------------------------------- > > Key: TEIID-3410 > URL: https://issues.jboss.org/browse/TEIID-3410 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.7 > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Fix For: 8.7.1.6_2, 8.11 > > > OData object URI does not resolve to a usable URL. When accessing a VDB via odata with a browser either via JSON or XML the uri listed in the metadata is not valid, it doesn't have the FQN of the table, only the type shows FQN: > "__metadata" : { > "uri" : "http://localhost:8080/odata/ODataRHQ/rhq_agent(10001)", > "type" : "RHQ32.rhq_agent" -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3358) Issues with entity set names

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3358?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3358: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1208515|https://bugzilla.redhat.com/show_bug.cgi?id=1208515] from ASSIGNED to MODIFIED > Issues with entity set names > ---------------------------- > > Key: TEIID-3358 > URL: https://issues.jboss.org/browse/TEIID-3358 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.7 > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Labels: Alpha1 > Fix For: 8.7.1.6_2, 8.11, 8.7.3 > > > The entity set name used for sql generation should be the fully qualified name. If there is for example two table with the same names in schemas visible to odata, but one of the tables does not have a key, then an ambiguous name exception will be thrown if an odata url is used with only the base table name. > It also appears that the URI link in the results metadata uses the non-qualified table name, which will have issues in the scenario above. > We may also need to document or add an additional check for ambiguity as the OData4j findEdmEntitySet logic will return the first matching entity, which is generally against our approach to resolving. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3490) WITH [TABLENAME] AS clause being sent to source query

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3490?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3490: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1224377|https://bugzilla.redhat.com/show_bug.cgi?id=1224377] from NEW to MODIFIED > WITH [TABLENAME] AS clause being sent to source query > ----------------------------------------------------- > > Key: TEIID-3490 > URL: https://issues.jboss.org/browse/TEIID-3490 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.7 > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Fix For: 8.7.1.6_2, 8.11 > > > The transformation for that table is: > WITH MONTHEND AS (SELECT CONVERT(SQLBqt.tinya.DateValue, DATE) AS REFERENCE_VALUE FROM SQLBqt.tinya WHERE SQLBqt.tinya.IntKey = 2) > SELECT > RATES.INTKEY, MAX(CASE WHEN RATES.INTKEY = 20 THEN RATES.STRINGKEY END) AS GBP_RATE, MAX(CASE WHEN RATES.INTKEY = 25 THEN RATES.STRINGKEY END) AS EUR_RATE, MAX(CASE WHEN RATES.INTKEY = 30 THEN RATES.STRINGKEY END) AS USD_RATE > FROM > Oraclebqt.dssmalla2 AS RATES > WHERE > (RATES.INTKEY IN (20, 25, 30)) AND (RATES.DATEVALUE = (SELECT MONTHEND.REFERENCE_VALUE FROM MONTHEND)) > GROUP BY RATES.INTKEY > source queries are showing the With clause being pushed down to Oracle and they shouldn't be. > 11:11:54,283 DEBUG [org.teiid.CONNECTOR] (Worker3_QueryProcessorQueue30) Vw26e70yOBmw.6.3.2 Processing NEW request: WITH MONTHEND (REFERENCE_VALUE) AS (SELECT CONVERT(g_0.DateValue, DATE) FROM SQLBqt.tinya AS g_0 WHERE g_0.IntKey = 2) SELECT g_0.INTKEY, MAX(CASE WHEN g_0.INTKEY = 20 THEN g_0.STRINGKEY END), MAX(CASE WHEN g_0.INTKEY = 25 THEN g_0.STRINGKEY END), MAX(CASE WHEN g_0.INTKEY = 30 THEN g_0.STRINGKEY END) FROM Oraclebqt.DSSMALLA2 AS g_0 WHERE (g_0.INTKEY IN (20, 25, 30)) AND (g_0.DATEVALUE = {d'2000-01-03'}) GROUP BY g_0.INTKEY > 11:11:54,283 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (Worker3_QueryProcessorQueue30) Oraclebqt: getConnection(null, WrappedConnectionRequestInfo@2efc4e0e[userName=bqt2]) [0/20] > 11:11:54,283 INFO [org.teiid.CONNECTOR] (Worker3_QueryProcessorQueue30) OracleExecutionFactory Commit=true;DatabaseProductName=Oracle;DatabaseProductVersion=Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production > With the Partitioning, OLAP, Data Mining and Real Application Testing options;DriverMajorVersion=11;DriverMajorVersion=2;DriverName=Oracle JDBC driver;DriverVersion=11.2.0.1.0;IsolationLevel=2 > 11:11:54,283 DEBUG [org.teiid.CONNECTOR] (Worker3_QueryProcessorQueue30) Vw26e70yOBmw.6.3.2 Obtained execution > 11:11:54,283 DEBUG [org.teiid.COMMAND_LOG] (Worker3_QueryProcessorQueue30) START DATA SRC COMMAND: startTime=2015-05-22 11:11:54.283 requestID=Vw26e70yOBmw.6 sourceCommandID=3 executionID=2 txID=null modelName=Oraclebqt translatorName=oracle sessionID=Vw26e70yOBmw principal=teiiduser@teiid-security sql=WITH MONTHEND (REFERENCE_VALUE) AS (SELECT CONVERT(g_0.DateValue, DATE) FROM SQLBqt.tinya AS g_0 WHERE g_0.IntKey = 2) SELECT g_0.INTKEY, MAX(CASE WHEN g_0.INTKEY = 20 THEN g_0.STRINGKEY END), MAX(CASE WHEN g_0.INTKEY = 25 THEN g_0.STRINGKEY END), MAX(CASE WHEN g_0.INTKEY = 30 THEN g_0.STRINGKEY END) FROM Oraclebqt.DSSMALLA2 AS g_0 WHERE (g_0.INTKEY IN (20, 25, 30)) AND (g_0.DATEVALUE = {d'2000-01-03'}) GROUP BY g_0.INTKEY > 11:11:54,285 DEBUG [org.teiid.CONNECTOR] (Worker3_QueryProcessorQueue30) Source-specific command: WITH MONTHEND AS (SELECT trunc(cast(g_0."DateValue" AS date)) AS REFERENCE_VALUE FROM "bqt2"."dbo"."tinya" g_0 WHERE g_0."IntKey" = 2) SELECT g_0."INTKEY", MAX(CASE WHEN g_0."INTKEY" = 20 THEN g_0."STRINGKEY" END), MAX(CASE WHEN g_0."INTKEY" = 25 THEN g_0."STRINGKEY" END), MAX(CASE WHEN g_0."INTKEY" = 30 THEN g_0."STRINGKEY" END) FROM "BQT2"."DSSMALLA2" g_0 WHERE g_0."INTKEY" IN (20, 25, 30) AND g_0."DATEVALUE" = {d '2000-01-03'} GROUP BY g_0."INTKEY" > 11:11:54,285 TRACE [org.teiid.CONNECTOR] (Worker3_QueryProcessorQueue30) Source sql WITH MONTHEND AS (SELECT trunc(cast(g_0."DateValue" AS date)) AS REFERENCE_VALUE FROM "bqt2"."dbo"."tinya" g_0 WHERE g_0."IntKey" = 2) SELECT g_0."INTKEY", MAX(CASE WHEN g_0."INTKEY" = 20 THEN g_0."STRINGKEY" END), MAX(CASE WHEN g_0."INTKEY" = 25 THEN g_0."STRINGKEY" END), MAX(CASE WHEN g_0."INTKEY" = 30 THEN g_0."STRINGKEY" END) FROM "BQT2"."DSSMALLA2" g_0 WHERE g_0."INTKEY" IN (20, 25, 30) AND g_0."DATEVALUE" = {d '2000-01-03'} GROUP BY g_0."INTKEY" > 11:11:55,514 DEBUG [org.teiid.COMMAND_LOG] (Worker3_QueryProcessorQueue30) ERROR SRC COMMAND: endTime=2015-05-22 11:11:55.514 requestID=Vw26e70yOBmw.6 sourceCommandID=3 executionID=2 txID=null modelName=Oraclebqt translatorName=oracle sessionID=Vw26e70yOBmw principal=teiiduser@teiid-security finalRowCount=null > 11:11:55,514 WARN [org.teiid.CONNECTOR] (Worker3_QueryProcessorQueue30) Connector worker process failed for atomic-request=Vw26e70yOBmw.6.3.2: org.teiid.translator.jdbc.JDBCExecutionException: 907 TEIID11008:TEIID11004 Error executing statement(s): [Prepared Values: [] SQL: WITH MONTHEND AS (SELECT trunc(cast(g_0."DateValue" AS date)) AS REFERENCE_VALUE FROM "bqt2"."dbo"."tinya" g_0 WHERE g_0."IntKey" = 2) SELECT g_0."INTKEY", MAX(CASE WHEN g_0."INTKEY" = 20 THEN g_0."STRINGKEY" END), MAX(CASE WHEN g_0."INTKEY" = 25 THEN g_0."STRINGKEY" END), MAX(CASE WHEN g_0."INTKEY" = 30 THEN g_0."STRINGKEY" END) FROM "BQT2"."DSSMALLA2" g_0 WHERE g_0."INTKEY" IN (20, 25, 30) AND g_0."DATEVALUE" = {d '2000-01-03'} GROUP BY g_0."INTKEY"] -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3538) Make OData V2 compatible with LINQPad

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3538?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3538: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1233383|https://bugzilla.redhat.com/show_bug.cgi?id=1233383] from NEW to MODIFIED > Make OData V2 compatible with LINQPad > ------------------------------------- > > Key: TEIID-3538 > URL: https://issues.jboss.org/browse/TEIID-3538 > Project: Teiid > Issue Type: Bug > Components: OData > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Labels: Final > Fix For: 8.7.1.6_2, 8.11 > > > Current OData V2 implementation is not able to load in LINQPad https://www.linqpad.net/ > Couple issues found > - List(Edm.xxx) based collections are not supported. V2 Spec did not specify any List based collections. Only Collection(Edm.xxx) type. So, part of TEIID-3471 need to be rolled back and fix with Collection(Edm.xxx) type > - Explicit definition of "not null" in Entity's key property. > - TEIID-3471 did not go far enough to define accepts header to have "application/xml", "application/atom+xml" and "application/json" without "chaset=utf-8" appended to it. TEIID-3471 only added $metadata and service document. BTW, I was under the impression that I did add all the required places, and was surprised not see in commit :( -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3555) Like expression in select statement fails against Sybase

by Bram Gadeyne (JIRA)

Bram Gadeyne created TEIID-3555: ----------------------------------- Summary: Like expression in select statement fails against Sybase Key: TEIID-3555 URL: https://issues.jboss.org/browse/TEIID-3555 Project: Teiid Issue Type: Feature Request Affects Versions: 8.9.1 Reporter: Bram Gadeyne Assignee: Steven Hawkins Priority: Minor Sometimes I use a like statement within the select statement to evaluate whether or not some text contains a certain sub-string. e.g: select outcome like '%died%' as died from patients Some databases support this and return a boolean value but others (like sybase) don't. This results in an exception "Incorrect syntax near keyword 'like'" Would is be possible to rewrite this for Sybase (and maybe others) to something like: select case when icuoutcomename like '%overleden%' then cast(1 as bit) else cast(0 as bit) end as mort from patients I used cast(1 as bit) and cast(0 as bit) here because it seems like Sybase does not support true and false. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3554) Audit log is missing details related to what role was applied and what info was allowed or denied

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3554?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3554: --------------------------------------- > If so, would be good if the role that is in the VDB that controls the access be written to audit log, but not put into the exception. So when its denied, only care what role thats important (and what the user doesn't have). The logic is not set up that way. A user has an associated set of roles and the permissions of those roles are checked. There is no general mapping of resource to permission across all roles known to a vdb (and the same permission could appear in many roles). > Additionally, when access is given, the role that was used for access Here again the same permission could appear in many roles that a user has. Which one is tested first does not matter. Reporting the full set will can further slow down permission processing. > Also, if the VDB is sequenced, a report could be run between metadata and audit log to analyze for any differences. I don't follow you here. Anything you would want to analyze could be done statically. > It would be a backdoor check to make sure no one changes the the VDB and gives access that isn't modeled thru the standard process. Can you elaborate on this scenario? Are you expecting that the metadata, the roles, the role mappings, etc. can be compromised? How would that happen and what non-compromised artifact are you comparing against? > Audit log is missing details related to what role was applied and what info was allowed or denied > ------------------------------------------------------------------------------------------------- > > Key: TEIID-3554 > URL: https://issues.jboss.org/browse/TEIID-3554 > Project: Teiid > Issue Type: Quality Risk > Components: Server > Affects Versions: 8.7.1.6_2 > Reporter: Van Halbert > Assignee: Steven Hawkins > Attachments: portfolioroles_data.xlsx > > > Using the dynamicvdb-dataroles quick start as the basis for triggering the audit log. Executing the view query: "Select * from StockPrice" . The query will only present the "price" column value when the user has the "prices" role. When performing queries with a user (name=teiidUser) that doesn't have the "prices" role versus one that does (name=portfolio), doesn't provide any discerning information in the audit log to indicate that a role was applied to the data. > Attaching excel file of the audit log data. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3553) Odata - if table name is ambiguous, teiid returns result from first table

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3553?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-3553: ------------------------------------- +1 exception scenario then. This is same behavior in JDBC protocol too for Teiid. > Odata - if table name is ambiguous, teiid returns result from first table > ------------------------------------------------------------------------- > > Key: TEIID-3553 > URL: https://issues.jboss.org/browse/TEIID-3553 > Project: Teiid > Issue Type: Quality Risk > Components: OData > Affects Versions: 8.7.1.6_2 > Reporter: Juraj Duráni > Assignee: Steven Hawkins > > If table name is ambiguous, teiid returns data from first matching table. I expect, that it should return error message similar to exception which is thrown via JDBC. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3554) Audit log is missing details related to what role was applied and what info was allowed or denied

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-3554?page=com.atlassian.jira.plugin... ] Van Halbert commented on TEIID-3554: ------------------------------------ Can the info that's put in the exception be different than what's written to the audit log? If so, would be good if the role that is in the VDB that controls the access be written to audit log, but not put into the exception. So when its denied, only care what role thats important (and what the user doesn't have). Additionally, when access is given, the role that was used for access. Also, if the VDB is sequenced, a report could be run between metadata and audit log to analyze for any differences. It would be a backdoor check to make sure no one changes the the VDB and gives access that isn't modeled thru the standard process. > Audit log is missing details related to what role was applied and what info was allowed or denied > ------------------------------------------------------------------------------------------------- > > Key: TEIID-3554 > URL: https://issues.jboss.org/browse/TEIID-3554 > Project: Teiid > Issue Type: Quality Risk > Components: Server > Affects Versions: 8.7.1.6_2 > Reporter: Van Halbert > Assignee: Steven Hawkins > Attachments: portfolioroles_data.xlsx > > > Using the dynamicvdb-dataroles quick start as the basis for triggering the audit log. Executing the view query: "Select * from StockPrice" . The query will only present the "price" column value when the user has the "prices" role. When performing queries with a user (name=teiidUser) that doesn't have the "prices" role versus one that does (name=portfolio), doesn't provide any discerning information in the audit log to indicate that a role was applied to the data. > Attaching excel file of the audit log data. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3553) Odata - if table name is ambiguous, teiid returns result from first table

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3553?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3553: --------------------------------------- > I would categorize this as invalid usage. It's not really invalid usage as we are allowing non-qualified names to be used. It's either something that we document about the v2 odata resolving or should change oreva to match Teiid's resolving and throw an exception. > Odata - if table name is ambiguous, teiid returns result from first table > ------------------------------------------------------------------------- > > Key: TEIID-3553 > URL: https://issues.jboss.org/browse/TEIID-3553 > Project: Teiid > Issue Type: Quality Risk > Components: OData > Affects Versions: 8.7.1.6_2 > Reporter: Juraj Duráni > Assignee: Steven Hawkins > > If table name is ambiguous, teiid returns data from first matching table. I expect, that it should return error message similar to exception which is thrown via JDBC. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues June 2015