February 2019 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-5659) Upgrade spring-boot version in example to match version in teiid-spring-boot

by Van Halbert (Jira)

[ https://issues.jboss.org/browse/TEIID-5659?page=com.atlassian.jira.plugin... ] Van Halbert commented on TEIID-5659: ------------------------------------ Also, would like to change the property name to match for ease of substitution. > Upgrade spring-boot version in example to match version in teiid-spring-boot > ----------------------------------------------------------------------------- > > Key: TEIID-5659 > URL: https://issues.jboss.org/browse/TEIID-5659 > Project: Teiid > Issue Type: Enhancement > Components: Build/Kits > Reporter: Van Halbert > Assignee: Van Halbert > Priority: Major > > Upgrade version of spring-boot in teiid-openshift-examples: > {code} > <version.spring-boot>1.5.13.RELEASE</version.spring-boot> > {code} > to match the version in teiid-spring-boot > {code} > <spring-boot.version>2.1.2.RELEASE</spring-boot.version> > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5659) Upgrade spring-boot version in example to match version in teiid-spring-boot

by Van Halbert (Jira)

Van Halbert created TEIID-5659: ---------------------------------- Summary: Upgrade spring-boot version in example to match version in teiid-spring-boot Key: TEIID-5659 URL: https://issues.jboss.org/browse/TEIID-5659 Project: Teiid Issue Type: Enhancement Components: Build/Kits Reporter: Van Halbert Assignee: Steven Hawkins Upgrade version of spring-boot in teiid-openshift-examples: {code} <version.spring-boot>1.5.13.RELEASE</version.spring-boot> {code} to match the version in teiid-spring-boot {code} <spring-boot.version>2.1.2.RELEASE</spring-boot.version> {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5659) Upgrade spring-boot version in example to match version in teiid-spring-boot

by Van Halbert (Jira)

[ https://issues.jboss.org/browse/TEIID-5659?page=com.atlassian.jira.plugin... ] Van Halbert reassigned TEIID-5659: ---------------------------------- Assignee: Van Halbert (was: Steven Hawkins) > Upgrade spring-boot version in example to match version in teiid-spring-boot > ----------------------------------------------------------------------------- > > Key: TEIID-5659 > URL: https://issues.jboss.org/browse/TEIID-5659 > Project: Teiid > Issue Type: Enhancement > Components: Build/Kits > Reporter: Van Halbert > Assignee: Van Halbert > Priority: Major > > Upgrade version of spring-boot in teiid-openshift-examples: > {code} > <version.spring-boot>1.5.13.RELEASE</version.spring-boot> > {code} > to match the version in teiid-spring-boot > {code} > <spring-boot.version>2.1.2.RELEASE</spring-boot.version> > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4449) Allow limited replanning of subplans that use only common tables

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-4449?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-4449: ---------------------------------- Fix Version/s: 8.12.17.6_4 > Allow limited replanning of subplans that use only common tables > ----------------------------------------------------------------- > > Key: TEIID-4449 > URL: https://issues.jboss.org/browse/TEIID-4449 > Project: Teiid > Issue Type: Enhancement > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 9.1, 8.12.17.6_4 > > > If a common table is fully pushed and not marked as materialized, then it could be used in subplans in a trivial way: > with x as ... select col from x > It would be better to have that access reference a materialized common table, rather than pushed separately. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5658) PG transport can sendResults before sync

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5658?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5658: --------------------------------------- > I remember reading the ready as no-op operation by the client. Is behavior same odbc client? Haven't debugged the pg odbc code yet. I've updated the issue. It's more narrow than I thought. It's actually that we're responding to execute before sync, and the client doesn't like that. > PG transport can sendResults before sync > ---------------------------------------- > > Key: TEIID-5658 > URL: https://issues.jboss.org/browse/TEIID-5658 > Project: Teiid > Issue Type: Bug > Components: ODBC > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.1, 12.0.1, 11.2.3 > > > The code is allowing for a sequence of events such as: > 2019-02-13 14:07:47.613 org.teiid.ODBC TRACE NIO4 invoking server method: prepare [, select oid from pg_class where relname='pg_class', []] > 2019-02-13 14:07:47.615 org.teiid.ODBC TRACE NIO4 invoking client method: org.teiid.transport.ODBCClientInstance$1@d875495 prepareCompleted [] > 2019-02-13 14:07:47.615 org.teiid.ODBC TRACE NIO4 invoking server method: bindParameters [, , [], 0, null, UTF-8] > 2019-02-13 14:07:47.615 org.teiid.ODBC TRACE NIO4 invoking client method: org.teiid.transport.ODBCClientInstance$1@d875495 bindComplete null > 2019-02-13 14:07:47.617 org.teiid.ODBC TRACE NIO4 invoking server method: getResultSetMetaDataDescription [] > 2019-02-13 14:07:47.617 org.teiid.ODBC TRACE NIO4 invoking client method: org.teiid.transport.ODBCClientInstance$1@d875495 sendResultSetDescription [[org.teiid.odbc.PGUtil$PgColInfo@1086babd], null] > 2019-02-13 14:07:47.617 org.teiid.ODBC TRACE NIO4 invoking server method: execute [, 0] > 2019-02-13 14:07:47.618 org.teiid.ODBC TRACE NIO4 invoking client method: org.teiid.transport.ODBCClientInstance$1@d875495 sendResults [null, org.teiid.jdbc.ResultSetImpl@1e1aed1a, [org.teiid.odbc.PGUtil$PgColInfo@1086babd], org.teiid.client.util.ResultsFuture@3b6cff36, FORWARD, -1, false, null] > 2019-02-13 14:07:47.619 org.teiid.ODBC TRACE NIO4 invoking server method: sync null > 2019-02-13 14:07:47.619 org.teiid.ODBC TRACE Worker0_QueryProcessorQueue368 invoking client method: org.teiid.transport.ODBCClientInstance$1@d875495 sendCommandComplete [select oid from pg_class where relname='pg_class', [1]] > 2019-02-13 14:07:47.619 org.teiid.ODBC TRACE NIO4 invoking client method: org.teiid.transport.ODBCClientInstance$1@d875495 ready [false, false] > That is after execute we are immediately responding with results. That response ahead of the sync causes issues in the pg jdbc driver such as reporting that there is no result set. See TEIID-5425 > This does not appear to be a requirement of the flow: https://www.postgresql.org/docs/9.3/protocol-flow.html#AEN99807 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5658) PG transport can sendResults before sync

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5658?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5658: ---------------------------------- Description: The code is allowing for a sequence of events such as: 2019-02-13 14:07:47.613 org.teiid.ODBC TRACE NIO4 invoking server method: prepare [, select oid from pg_class where relname='pg_class', []] 2019-02-13 14:07:47.615 org.teiid.ODBC TRACE NIO4 invoking client method: org.teiid.transport.ODBCClientInstance$1@d875495 prepareCompleted [] 2019-02-13 14:07:47.615 org.teiid.ODBC TRACE NIO4 invoking server method: bindParameters [, , [], 0, null, UTF-8] 2019-02-13 14:07:47.615 org.teiid.ODBC TRACE NIO4 invoking client method: org.teiid.transport.ODBCClientInstance$1@d875495 bindComplete null 2019-02-13 14:07:47.617 org.teiid.ODBC TRACE NIO4 invoking server method: getResultSetMetaDataDescription [] 2019-02-13 14:07:47.617 org.teiid.ODBC TRACE NIO4 invoking client method: org.teiid.transport.ODBCClientInstance$1@d875495 sendResultSetDescription [[org.teiid.odbc.PGUtil$PgColInfo@1086babd], null] 2019-02-13 14:07:47.617 org.teiid.ODBC TRACE NIO4 invoking server method: execute [, 0] 2019-02-13 14:07:47.618 org.teiid.ODBC TRACE NIO4 invoking client method: org.teiid.transport.ODBCClientInstance$1@d875495 sendResults [null, org.teiid.jdbc.ResultSetImpl@1e1aed1a, [org.teiid.odbc.PGUtil$PgColInfo@1086babd], org.teiid.client.util.ResultsFuture@3b6cff36, FORWARD, -1, false, null] 2019-02-13 14:07:47.619 org.teiid.ODBC TRACE NIO4 invoking server method: sync null 2019-02-13 14:07:47.619 org.teiid.ODBC TRACE Worker0_QueryProcessorQueue368 invoking client method: org.teiid.transport.ODBCClientInstance$1@d875495 sendCommandComplete [select oid from pg_class where relname='pg_class', [1]] 2019-02-13 14:07:47.619 org.teiid.ODBC TRACE NIO4 invoking client method: org.teiid.transport.ODBCClientInstance$1@d875495 ready [false, false] That is after execute we are immediately responding with results. That response ahead of the sync causes issues in the pg jdbc driver such as reporting that there is no result set. See TEIID-5425 This does not appear to be a requirement of the flow: https://www.postgresql.org/docs/9.3/protocol-flow.html#AEN99807 was: The code is allowing for a sequence of events such as: 2019-02-13 12:26:55.159 org.teiid.ODBC TRACE NIO1 invoking server method: execute [, 0] 2019-02-13 12:26:55.163 org.teiid.ODBC TRACE NIO1 invoking client method: sendResults [null, org.teiid.jdbc.ResultSetImpl@1a79693d, [org.teiid.odbc.PGUtil$PgColInfo@79f0f194], org.teiid.client.util.ResultsFuture@64fb47b7, FORWARD, -1, false, null] 2019-02-13 12:26:55.163 org.teiid.ODBC TRACE Worker5_QueryProcessorQueue533 invoking client method: sendCommandComplete [select oid from pg_class where relname='pg_class', [1]] 2019-02-13 12:26:55.163 org.teiid.ODBC TRACE Worker5_QueryProcessorQueue533 invoking client method: ready [false, false] 2019-02-13 12:26:55.163 org.teiid.ODBC TRACE NIO1 invoking server method: sync null 2019-02-13 12:26:55.163 org.teiid.ODBC TRACE NIO1 invoking client method: ready [false, false] That is after execute we are immediately responding with results, command complete, and ready. Then we see a sync and respond with ready again. The first ready is not expected - it should not be issued until after the sync. The causes issues in the pg jdbc driver such as reporting that there is no result set. See TEIID-5425 > PG transport can sendResults before sync > ---------------------------------------- > > Key: TEIID-5658 > URL: https://issues.jboss.org/browse/TEIID-5658 > Project: Teiid > Issue Type: Bug > Components: ODBC > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.1, 12.0.1, 11.2.3 > > > The code is allowing for a sequence of events such as: > 2019-02-13 14:07:47.613 org.teiid.ODBC TRACE NIO4 invoking server method: prepare [, select oid from pg_class where relname='pg_class', []] > 2019-02-13 14:07:47.615 org.teiid.ODBC TRACE NIO4 invoking client method: org.teiid.transport.ODBCClientInstance$1@d875495 prepareCompleted [] > 2019-02-13 14:07:47.615 org.teiid.ODBC TRACE NIO4 invoking server method: bindParameters [, , [], 0, null, UTF-8] > 2019-02-13 14:07:47.615 org.teiid.ODBC TRACE NIO4 invoking client method: org.teiid.transport.ODBCClientInstance$1@d875495 bindComplete null > 2019-02-13 14:07:47.617 org.teiid.ODBC TRACE NIO4 invoking server method: getResultSetMetaDataDescription [] > 2019-02-13 14:07:47.617 org.teiid.ODBC TRACE NIO4 invoking client method: org.teiid.transport.ODBCClientInstance$1@d875495 sendResultSetDescription [[org.teiid.odbc.PGUtil$PgColInfo@1086babd], null] > 2019-02-13 14:07:47.617 org.teiid.ODBC TRACE NIO4 invoking server method: execute [, 0] > 2019-02-13 14:07:47.618 org.teiid.ODBC TRACE NIO4 invoking client method: org.teiid.transport.ODBCClientInstance$1@d875495 sendResults [null, org.teiid.jdbc.ResultSetImpl@1e1aed1a, [org.teiid.odbc.PGUtil$PgColInfo@1086babd], org.teiid.client.util.ResultsFuture@3b6cff36, FORWARD, -1, false, null] > 2019-02-13 14:07:47.619 org.teiid.ODBC TRACE NIO4 invoking server method: sync null > 2019-02-13 14:07:47.619 org.teiid.ODBC TRACE Worker0_QueryProcessorQueue368 invoking client method: org.teiid.transport.ODBCClientInstance$1@d875495 sendCommandComplete [select oid from pg_class where relname='pg_class', [1]] > 2019-02-13 14:07:47.619 org.teiid.ODBC TRACE NIO4 invoking client method: org.teiid.transport.ODBCClientInstance$1@d875495 ready [false, false] > That is after execute we are immediately responding with results. That response ahead of the sync causes issues in the pg jdbc driver such as reporting that there is no result set. See TEIID-5425 > This does not appear to be a requirement of the flow: https://www.postgresql.org/docs/9.3/protocol-flow.html#AEN99807 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5658) PG transport can sendResults before sync

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5658?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5658: ---------------------------------- Summary: PG transport can sendResults before sync (was: PG transport can send multiple read messages) > PG transport can sendResults before sync > ---------------------------------------- > > Key: TEIID-5658 > URL: https://issues.jboss.org/browse/TEIID-5658 > Project: Teiid > Issue Type: Bug > Components: ODBC > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.1, 12.0.1, 11.2.3 > > > The code is allowing for a sequence of events such as: > 2019-02-13 12:26:55.159 org.teiid.ODBC TRACE NIO1 invoking server method: execute [, 0] > 2019-02-13 12:26:55.163 org.teiid.ODBC TRACE NIO1 invoking client method: sendResults [null, org.teiid.jdbc.ResultSetImpl@1a79693d, [org.teiid.odbc.PGUtil$PgColInfo@79f0f194], org.teiid.client.util.ResultsFuture@64fb47b7, FORWARD, -1, false, null] > 2019-02-13 12:26:55.163 org.teiid.ODBC TRACE Worker5_QueryProcessorQueue533 invoking client method: sendCommandComplete [select oid from pg_class where relname='pg_class', [1]] > 2019-02-13 12:26:55.163 org.teiid.ODBC TRACE Worker5_QueryProcessorQueue533 invoking client method: ready [false, false] > 2019-02-13 12:26:55.163 org.teiid.ODBC TRACE NIO1 invoking server method: sync null > 2019-02-13 12:26:55.163 org.teiid.ODBC TRACE NIO1 invoking client method: ready [false, false] > That is after execute we are immediately responding with results, command complete, and ready. Then we see a sync and respond with ready again. > The first ready is not expected - it should not be issued until after the sync. > The causes issues in the pg jdbc driver such as reporting that there is no result set. See TEIID-5425 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5658) PG transport can send multiple read messages

by Ramesh Reddy (Jira)

[ https://issues.jboss.org/browse/TEIID-5658?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-5658: ------------------------------------- So "command complete" should wait for ack, which is "sync" before "ready" is sent. For some reason, I remember reading the ready as no-op operation by the client. Is behavior same odbc client? > PG transport can send multiple read messages > -------------------------------------------- > > Key: TEIID-5658 > URL: https://issues.jboss.org/browse/TEIID-5658 > Project: Teiid > Issue Type: Bug > Components: ODBC > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.1, 12.0.1, 11.2.3 > > > The code is allowing for a sequence of events such as: > 2019-02-13 12:26:55.159 org.teiid.ODBC TRACE NIO1 invoking server method: execute [, 0] > 2019-02-13 12:26:55.163 org.teiid.ODBC TRACE NIO1 invoking client method: sendResults [null, org.teiid.jdbc.ResultSetImpl@1a79693d, [org.teiid.odbc.PGUtil$PgColInfo@79f0f194], org.teiid.client.util.ResultsFuture@64fb47b7, FORWARD, -1, false, null] > 2019-02-13 12:26:55.163 org.teiid.ODBC TRACE Worker5_QueryProcessorQueue533 invoking client method: sendCommandComplete [select oid from pg_class where relname='pg_class', [1]] > 2019-02-13 12:26:55.163 org.teiid.ODBC TRACE Worker5_QueryProcessorQueue533 invoking client method: ready [false, false] > 2019-02-13 12:26:55.163 org.teiid.ODBC TRACE NIO1 invoking server method: sync null > 2019-02-13 12:26:55.163 org.teiid.ODBC TRACE NIO1 invoking client method: ready [false, false] > That is after execute we are immediately responding with results, command complete, and ready. Then we see a sync and respond with ready again. > The first ready is not expected - it should not be issued until after the sync. > The causes issues in the pg jdbc driver such as reporting that there is no result set. See TEIID-5425 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-35) Write example to show Keycloak based OData access in OpenShift

by Ramesh Reddy (Jira)

Ramesh Reddy created TEIIDSB-35: ----------------------------------- Summary: Write example to show Keycloak based OData access in OpenShift Key: TEIIDSB-35 URL: https://issues.jboss.org/browse/TEIIDSB-35 Project: Teiid Spring Boot Issue Type: Task Components: examples, OData, OpenShift Reporter: Ramesh Reddy This example should provide detailed instructions to deploy/use existing Keycloak instance in the OpenShift to be used with the Teiid based service. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIIDSB-34) Support Keycloak based OAuth authentication for OData

by Ramesh Reddy (Jira)

Ramesh Reddy created TEIIDSB-34: ----------------------------------- Summary: Support Keycloak based OAuth authentication for OData Key: TEIIDSB-34 URL: https://issues.jboss.org/browse/TEIIDSB-34 Project: Teiid Spring Boot Issue Type: Feature Request Components: OData Reporter: Ramesh Reddy Provide Keycloak based oAuth2 authentication on top of OData API. This needs to be an optional feature either exposed through a flag or starter project in the pom.xml file. The scope in the OAuth needs to be used as the roles in the Teiid (this is how legacy Teiid mapped) -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues February 2019