April 2016 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-4017) EXECUTE IMMEDIATE in anonymous procedure ignores permissions

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-4017?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-4017: ------------------------------------------------ jolee(a)redhat.com changed the Status of [bug 1314863|https://bugzilla.redhat.com/show_bug.cgi?id=1314863] from ON_QA to VERIFIED > EXECUTE IMMEDIATE in anonymous procedure ignores permissions > ------------------------------------------------------------ > > Key: TEIID-4017 > URL: https://issues.jboss.org/browse/TEIID-4017 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.12 > Environment: teiid-8.12-Beta1 on Red Hat JBoss Enterprise Application Platform - Version 6.3.0.GA > Reporter: dalex dalex > Assignee: Steven Hawkins > Priority: Blocker > Fix For: 9.0, 8.12.5, 8.13.2, 8.7.5.6_2 > > > I've found a bug when executing a query in the EXECUTE IMMEDIATE clause. It ignores permissions. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-4008) Sending teiid varbinary value (x'') to Microsoft SQL Server errors

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-4008?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-4008: ------------------------------------------------ jolee(a)redhat.com changed the Status of [bug 1313407|https://bugzilla.redhat.com/show_bug.cgi?id=1313407] from MODIFIED to ASSIGNED > Sending teiid varbinary value (x'') to Microsoft SQL Server errors > ------------------------------------------------------------------ > > Key: TEIID-4008 > URL: https://issues.jboss.org/browse/TEIID-4008 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 8.7.2.6_2 > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Fix For: 9.0, 8.12.5, 8.13.2, 8.7.5.6_2 > > > When sending a query to Microsoft SQL Server with a varbinary in criteria: > select * from debBinary where ipv6= x'FFFF6BBE85D8' > It pushes the criteria to Microsoft SQL Server, but as X'FFFF6BBE85D8'[1] so Microsoft gives the syntax error[2] and needs to just be select * from debBinary where ipv6= 'FFFF6BBE85D8': > [1]14:26:08,951 DEBUG [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue8) Source-specific command: SELECT g_0."id", g_0."ipv6" FROM "bqt2"."dbo"."debbinary" g_0 WHERE g_0."ipv6" = X'FFFF6BBE85D8' > [2] com.microsoft.sqlserver.jdbc.SQLServerException: Incorrect syntax near 'FFFF6BBE85D8'. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-4008) Sending teiid varbinary value (x'') to Microsoft SQL Server errors

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-4008?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-4008: ------------------------------------------------ jolee(a)redhat.com changed the Status of [bug 1313407|https://bugzilla.redhat.com/show_bug.cgi?id=1313407] from ASSIGNED to MODIFIED > Sending teiid varbinary value (x'') to Microsoft SQL Server errors > ------------------------------------------------------------------ > > Key: TEIID-4008 > URL: https://issues.jboss.org/browse/TEIID-4008 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 8.7.2.6_2 > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Fix For: 9.0, 8.12.5, 8.13.2, 8.7.5.6_2 > > > When sending a query to Microsoft SQL Server with a varbinary in criteria: > select * from debBinary where ipv6= x'FFFF6BBE85D8' > It pushes the criteria to Microsoft SQL Server, but as X'FFFF6BBE85D8'[1] so Microsoft gives the syntax error[2] and needs to just be select * from debBinary where ipv6= 'FFFF6BBE85D8': > [1]14:26:08,951 DEBUG [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue8) Source-specific command: SELECT g_0."id", g_0."ipv6" FROM "bqt2"."dbo"."debbinary" g_0 WHERE g_0."ipv6" = X'FFFF6BBE85D8' > [2] com.microsoft.sqlserver.jdbc.SQLServerException: Incorrect syntax near 'FFFF6BBE85D8'. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-4114) Expanding logic in the format conversion for parsing and formatting of dates

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-4114?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-4114: --------------------------------- Fix Version/s: 8.7.5.6_2 > Expanding logic in the format conversion for parsing and formatting of dates > ---------------------------------------------------------------------------- > > Key: TEIID-4114 > URL: https://issues.jboss.org/browse/TEIID-4114 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 8.11 > Reporter: Johnathon Lee > Assignee: Steven Hawkins > Fix For: 9.0, 8.12.5, 8.7.5.6_2 > > > Java documentation isn't explicit https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html regarding date/time formats. > The format string is not enforced on the parsing side, so any hour format will accept any value. However oracle's behavior is different - if you specify HH vs HH24, then 13-23 is disallowed. > Need to address this by expanding the logic in the format conversion to account for the difference between parsing and formatting. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-4114) Expanding logic in the format conversion for parsing and formatting of dates

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-4114?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-4114: ------------------------------------------------ jolee(a)redhat.com changed the Status of [bug 1323312|https://bugzilla.redhat.com/show_bug.cgi?id=1323312] from NEW to MODIFIED > Expanding logic in the format conversion for parsing and formatting of dates > ---------------------------------------------------------------------------- > > Key: TEIID-4114 > URL: https://issues.jboss.org/browse/TEIID-4114 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 8.11 > Reporter: Johnathon Lee > Assignee: Steven Hawkins > Fix For: 9.0, 8.12.5 > > > Java documentation isn't explicit https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html regarding date/time formats. > The format string is not enforced on the parsing side, so any hour format will accept any value. However oracle's behavior is different - if you specify HH vs HH24, then 13-23 is disallowed. > Need to address this by expanding the logic in the format conversion to account for the difference between parsing and formatting. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-4114) Expanding logic in the format conversion for parsing and formatting of dates

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4114?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-4114. ----------------------------------- Resolution: Done Differentiated the parse/format so that we'll use HH24 for parsing. > Expanding logic in the format conversion for parsing and formatting of dates > ---------------------------------------------------------------------------- > > Key: TEIID-4114 > URL: https://issues.jboss.org/browse/TEIID-4114 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 8.11 > Reporter: Johnathon Lee > Assignee: Steven Hawkins > Fix For: 9.0, 8.12.5 > > > Java documentation isn't explicit https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html regarding date/time formats. > The format string is not enforced on the parsing side, so any hour format will accept any value. However oracle's behavior is different - if you specify HH vs HH24, then 13-23 is disallowed. > Need to address this by expanding the logic in the format conversion to account for the difference between parsing and formatting. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-4114) Expanding logic in the format conversion for parsing and formatting of dates

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4114?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-4114: ---------------------------------- Component/s: JDBC Connector Fix Version/s: 9.0 8.12.5 Workaround Description: Use HH for the hour format. Workaround: Workaround Exists Affects Version/s: 8.11 > Expanding logic in the format conversion for parsing and formatting of dates > ---------------------------------------------------------------------------- > > Key: TEIID-4114 > URL: https://issues.jboss.org/browse/TEIID-4114 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 8.11 > Reporter: Johnathon Lee > Assignee: Steven Hawkins > Fix For: 9.0, 8.12.5 > > > Java documentation isn't explicit https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html regarding date/time formats. > The format string is not enforced on the parsing side, so any hour format will accept any value. However oracle's behavior is different - if you specify HH vs HH24, then 13-23 is disallowed. > Need to address this by expanding the logic in the format conversion to account for the difference between parsing and formatting. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-4106) Rename and align infinispan translators/resource-adapters for their purpose

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4106?page=com.atlassian.jira.plugin... ] Van Halbert commented on TEIID-4106: ------------------------------------ Deprecating translator: infinispan-cache-dsl and point to use infinispan-cache-hotrod > Rename and align infinispan translators/resource-adapters for their purpose > ---------------------------------------------------------------------------- > > Key: TEIID-4106 > URL: https://issues.jboss.org/browse/TEIID-4106 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Affects Versions: 9.x > Reporter: Van Halbert > Assignee: Van Halbert > Fix For: 9.0 > > > The infinispan-cache and infinispan-cache-dsl translators/resource-adapters need to be renamed and aligned for what their purpose is. Because using "dsl" as part of the name is confusing, because both translators now support querying using JDG DSL language. > infinispan-cache: > - rename to infinispan-cache-library-mode (or leave as infinispan-cache and it be assume library mode) > - deprecate the access to remote-cache because the other infinispan-cache-dsl translator provides this feature. > - this will enable the cleaning of the documentation to be specific to library mode > infinispan-cache-dsl: > - rename to infinispan-cache-hot-rod (or something other than "dsl") because this all about remote cache access using hot rod client -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-4113) Impala translator - Incorrect aggregate replacement in query

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4113?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4113: --------------------------------------- > Should be able to produce the issue with the //Teiid query block that produces the output seen in the //Query sent to Impala block above. Here's the abridged version of a BaseQueryTest that I'm running on master/8.13.3 with the simple query expression for the view definition, which confirms the appropriate source query: {code} public void testQuery() throws Exception{ ImpalaExecutionFactory ief = new ImpalaExecutionFactory(); ief.setDatabaseVersion("2.0"); ief.start(); DefaultCapabilitiesFinder finder = new DefaultCapabilitiesFinder(CapabilitiesConverter.convertCapabilities(ief)); HardcodedDataManager dataMgr = new HardcodedDataManager(); List<?>[] expected = new List<?>[] { }; dataMgr.addData("SELECT g_0.the_attribute, convert((SUM(g_0.first_metric) / convert(COUNT(DISTINCT CASE WHEN g_0.second_metric >= 0 THEN g_0.second_metric END), long)), double), g_0.another_attribute FROM y.SourceTable AS g_0 WHERE g_0.a_filter_val = 111 GROUP BY g_0.the_attribute, g_0.another_attribute", //$NON-NLS-1$ expected); doProcess(RealMetadataFactory.fromDDL("create foreign table SourceTable (the_attribute string(255), first_metric long, second_metric bigdecimal, another_attribute String(255), a_filter_val integer); " + " create view VirtualTable (the_attribute string(255), first_metric long, second_metric bigdecimal, another_attribute String(255), a_filter_val integer) as (select * from SourceTable)", "x", "y"), "SELECT the_attribute, cast( sum( first_metric ) / count( distinct case when second_metric >= 0 then second_metric end ) as double ) as some_alias, PARSETIMESTAMP(another_attribute, 'yyyy-MM-dd') as somedate FROM VirtualTable WHERE a_filter_val=111 GROUP BY the_attribute, another_attribute", //$NON-NLS-1$ finder, dataMgr, expected, DEBUG); } } {code} So there must be a few more needed details. > Impala translator - Incorrect aggregate replacement in query > ------------------------------------------------------------ > > Key: TEIID-4113 > URL: https://issues.jboss.org/browse/TEIID-4113 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 8.13.3 > Environment: Ubuntu Trusty > Reporter: Don Krapohl > Assignee: Steven Hawkins > Labels: Impala_Translator > > When PARSETIMESTAMP is included in a query aggregates in other columns may not be written correctly. Example is as below, sum(first_metric) is rewritten to anon_grp0.agg0 in the query sent to Impala. > Given the schema: > //source > SourceTable > the_attribute string(255), > first_metric long, > second_metric bigdecimal > another_attribute String(255) > //view > VirtualTable > the_attribute string(255), > first_metric long, > second_metric bigdecimal > another_attribute String(255) > // Teiid query > SELECT the_attribute, > cast( > sum( > first_metric > ) > / > count( > distinct case when second_metric >= 0 then second_metric end > ) as double > ) as some_alias, > PARSETIMESTAMP(another_attribute, 'yyyy-MM-dd') as somedate > FROM VirtualTable > WHERE a_filter_val=111 > GROUP BY the_attribute, another_attribute > //Query sent to impala > SELECT g_0.the_attribute AS c_0, > cast( > ( > anon_grp0.agg0 > / > cast( > anon_grp0.agg1 AS bigint > ) > ) AS double > ) AS c_1, > g_0.another_attribute AS c_2 > FROM VirtualTable > WHERE a_filter_val=111 > GROUP BY g_0.the_attribute, g_0.another_attribute -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-4114) Expanding logic in the format conversion for parsing and formatting of dates

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-4114?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-4114: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1323312 Bugzilla Update: Perform > Expanding logic in the format conversion for parsing and formatting of dates > ---------------------------------------------------------------------------- > > Key: TEIID-4114 > URL: https://issues.jboss.org/browse/TEIID-4114 > Project: Teiid > Issue Type: Bug > Reporter: Johnathon Lee > Assignee: Steven Hawkins > > Java documentation isn't explicit https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html regarding date/time formats. > The format string is not enforced on the parsing side, so any hour format will accept any value. However oracle's behavior is different - if you specify HH vs HH24, then 13-23 is disallowed. > Need to address this by expanding the logic in the format conversion to account for the difference between parsing and formatting. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues April 2016