September 2016 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-4430) Update the Olingo library to 4.3

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4430?page=com.atlassian.jira.plugin... ] Ramesh Reddy resolved TEIID-4430. --------------------------------- Resolution: Done Labels: CR1 (was: ) Updated to Olingo 4.3.0 > Update the Olingo library to 4.3 > -------------------------------- > > Key: TEIID-4430 > URL: https://issues.jboss.org/browse/TEIID-4430 > Project: Teiid > Issue Type: Task > Components: OData > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Labels: CR1 > Fix For: 9.1 > > > Upgrade the Olingo to 4.3 version. This is currently in beta but will be in final by the time 9.1 releases. Also this is required for $expand and future data aggregation capabilities. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 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 resolved TEIID-4449. ----------------------------------- Resolution: Done Updated the planner to consolidate how the with clause is assigned to source queries and to check for repeated usage of the same common table, which triggers a replanning with the common table effectively marked as materialized. > 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 > Fix For: 9.1 > > > 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 (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4454) Close session called with null session id

by Wouter de Vaal (JIRA)

[ https://issues.jboss.org/browse/TEIID-4454?page=com.atlassian.jira.plugin... ] Wouter de Vaal commented on TEIID-4454: --------------------------------------- Ok I see now. I guess we are using an older version. > Close session called with null session id > ----------------------------------------- > > Key: TEIID-4454 > URL: https://issues.jboss.org/browse/TEIID-4454 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 9.0.4 > Reporter: Wouter de Vaal > Assignee: Steven Hawkins > Priority: Minor > > When connecting locally via a JNDI resource to a vdb, we see in our audit log that an extra closeSession is logged with a null session id, just before a new session is created. > This is probably because the class LocalServerConnection.authenticate calls logoff > Logoff will execute a logoff command with swallowing all exceptions: > try { > //make a best effort to send the logoff > Future<?> writeFuture = this.getService(ILogon.class).logoff(); > if (writeFuture != null) { > writeFuture.get(5000, TimeUnit.MILLISECONDS); > } > } catch (Exception e) { > //ignore > } > And this method will call closeSession without even checking if there is a session to logoff: > try { > this.service.closeSession(workContext.getSessionId()); > } finally { > this.updateDQPContext(new SessionMetadata()); > } > So fix should probably be adding an if statement to LogofImpl.logoff -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4454) Close session called with null session id

by Wouter de Vaal (JIRA)

[ https://issues.jboss.org/browse/TEIID-4454?page=com.atlassian.jira.plugin... ] Wouter de Vaal closed TEIID-4454. --------------------------------- Resolution: Out of Date > Close session called with null session id > ----------------------------------------- > > Key: TEIID-4454 > URL: https://issues.jboss.org/browse/TEIID-4454 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 9.0.4 > Reporter: Wouter de Vaal > Assignee: Steven Hawkins > Priority: Minor > > When connecting locally via a JNDI resource to a vdb, we see in our audit log that an extra closeSession is logged with a null session id, just before a new session is created. > This is probably because the class LocalServerConnection.authenticate calls logoff > Logoff will execute a logoff command with swallowing all exceptions: > try { > //make a best effort to send the logoff > Future<?> writeFuture = this.getService(ILogon.class).logoff(); > if (writeFuture != null) { > writeFuture.get(5000, TimeUnit.MILLISECONDS); > } > } catch (Exception e) { > //ignore > } > And this method will call closeSession without even checking if there is a session to logoff: > try { > this.service.closeSession(workContext.getSessionId()); > } finally { > this.updateDQPContext(new SessionMetadata()); > } > So fix should probably be adding an if statement to LogofImpl.logoff -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4457) Impala/Hive pushdown function definitions

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4457?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-4457. ----------------------------------- Resolution: Done Updated to use long instead and added another form of unix_timestamp > Impala/Hive pushdown function definitions > ----------------------------------------- > > Key: TEIID-4457 > URL: https://issues.jboss.org/browse/TEIID-4457 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 8.12 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.1, 9.0.5 > > > The impala/hive pushdown functions are defined accepting biginteger, but it should be a long (which maps to the source type of bigint). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4457) Impala/Hive pushdown function definitions

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-4457: ------------------------------------- Summary: Impala/Hive pushdown function definitions Key: TEIID-4457 URL: https://issues.jboss.org/browse/TEIID-4457 Project: Teiid Issue Type: Bug Components: JDBC Connector Affects Versions: 8.12 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 9.1, 9.0.5 The impala/hive pushdown functions are defined accepting biginteger, but it should be a long (which maps to the source type of bigint). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4454) Close session called with null session id

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4454?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4454: --------------------------------------- > And this method will call closeSession without even checking if there is a session to logoff Perhaps you are seeing something else. What you are describing does not match the code as the logoff method does check for a null session id: {code} if (workContext.getSession().isClosed() || workContext.getSessionId() == null) { if (workContext.getSessionId() != null) { this.updateDQPContext(new SessionMetadata()); } return ResultsFuture.NULL_FUTURE; } {code} Are you using a server version older than when TEIID-3664 was committed? > Close session called with null session id > ----------------------------------------- > > Key: TEIID-4454 > URL: https://issues.jboss.org/browse/TEIID-4454 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 9.0.4 > Reporter: Wouter de Vaal > Assignee: Steven Hawkins > Priority: Minor > > When connecting locally via a JNDI resource to a vdb, we see in our audit log that an extra closeSession is logged with a null session id, just before a new session is created. > This is probably because the class LocalServerConnection.authenticate calls logoff > Logoff will execute a logoff command with swallowing all exceptions: > try { > //make a best effort to send the logoff > Future<?> writeFuture = this.getService(ILogon.class).logoff(); > if (writeFuture != null) { > writeFuture.get(5000, TimeUnit.MILLISECONDS); > } > } catch (Exception e) { > //ignore > } > And this method will call closeSession without even checking if there is a session to logoff: > try { > this.service.closeSession(workContext.getSessionId()); > } finally { > this.updateDQPContext(new SessionMetadata()); > } > So fix should probably be adding an if statement to LogofImpl.logoff -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2578) add/remove schema elements

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-2578?page=com.atlassian.jira.plugin... ] Ramesh Reddy updated TEIID-2578: -------------------------------- Fix Version/s: 9.2 (was: 9.1) > add/remove schema elements > -------------------------- > > Key: TEIID-2578 > URL: https://issues.jboss.org/browse/TEIID-2578 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Fix For: 9.2 > > > Schemas are currently static after load. Modifications can only happen with restarts or new versions. We should allow add/drop at runtime. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4456) Enable the abiltiy to specify all the message descriptors when using protobuf configuration

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4456?page=com.atlassian.jira.plugin... ] Van Halbert updated TEIID-4456: ------------------------------- Description: Change configuration to enable the specification of all the protobuf descriptors to use. Currently, only the root protobuf descriptor is configured in the resource-adapter. Example: {code} <config-property name="MessageDescriptor"> bigdata.DataEntity </config-property> {code} and expect the .proto file to configure the relationship for the child descriptor within the parent: Example: {code} package bigdata; message DataEntity { .. optional MetaData context = 6; message MetaData { ... } } {code} and the metadata process can derive the children descriptors from the root descriptor. However, if all message descriptors are specified, that would allow for defining children message at the root level (outside the parent). And would allow the message descriptor to be shared among other messages. was: Change configuration to enable the specification of all the protobuf descriptors to use. Currently, only the root protobuf descriptor is configured. Example: {code} <config-property name="MessageDescriptor"> bigdata.DataEntity </config-property> {code} Because of this, the children message descriptors have to be defined within the parent message descriptor. If all message descriptors can be specified, then children message descriptors can be defined at the top level and shared. > Enable the abiltiy to specify all the message descriptors when using protobuf configuration > ------------------------------------------------------------------------------------------- > > Key: TEIID-4456 > URL: https://issues.jboss.org/browse/TEIID-4456 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Affects Versions: 9.2 > Reporter: Van Halbert > Assignee: Van Halbert > > Change configuration to enable the specification of all the protobuf descriptors to use. > Currently, only the root protobuf descriptor is configured in the resource-adapter. Example: > {code} > <config-property name="MessageDescriptor"> > bigdata.DataEntity > </config-property> > {code} > > and expect the .proto file to configure the relationship for the child descriptor within the parent: > Example: > {code} > package bigdata; > message DataEntity { > .. > optional MetaData context = 6; > message MetaData { > ... > } > } > {code} > and the metadata process can derive the children descriptors from the root descriptor. > However, if all message descriptors are specified, that would allow for defining children message at the root level (outside the parent). And would allow the message descriptor to be shared among other messages. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4456) Enable the abiltiy to specify all the message descriptors when using protobuf configuration

by Van Halbert (JIRA)

Van Halbert created TEIID-4456: ---------------------------------- Summary: Enable the abiltiy to specify all the message descriptors when using protobuf configuration Key: TEIID-4456 URL: https://issues.jboss.org/browse/TEIID-4456 Project: Teiid Issue Type: Enhancement Components: Misc. Connectors Affects Versions: 9.2 Reporter: Van Halbert Assignee: Steven Hawkins Change configuration to enable the specification of all the protobuf descriptors to use. Currently, only the root protobuf descriptor is configured. Example: {code} <config-property name="MessageDescriptor"> bigdata.DataEntity </config-property> {code} Because of this, the children message descriptors have to be defined within the parent message descriptor. If all message descriptors can be specified, then children message descriptors can be defined at the top level and shared. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues September 2016