October 2017 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-5129) File translator Java 6 issue

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5129?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5129. ----------------------------------- Resolution: Won't Fix Resolving as won't fix for now. > File translator Java 6 issue > ---------------------------- > > Key: TEIID-5129 > URL: https://issues.jboss.org/browse/TEIID-5129 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.12.x-6.4 > Reporter: Jan Stastny > Assignee: Steven Hawkins > Priority: Blocker > > In file translator (FileExecutionFactory.java) there is usage of java.nio.file.Files and java.nio.file.attribute.FileTime classes, which are since Java 1.7 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5130) Document/refine behavior of treating result parameter as the first parameter

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-5130?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-5130: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1507641 Bugzilla Update: Perform > Document/refine behavior of treating result parameter as the first parameter > ---------------------------------------------------------------------------- > > Key: TEIID-5130 > URL: https://issues.jboss.org/browse/TEIID-5130 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 10.0, 9.3.5 > > > DDL and metadata import make the assumption that the return parameter is the first in the underlying metadata (in part to ensure support of varargs), but we still allowed the result parameter to appear anywhere in the parameter list as to maintain backwards compatibility with legacy/Designer ddl. However in index metadata there is slightly different behavior in that the result parameter remains in it's original position. > We need to clarify this behavior - more documentation, enforce/validate that the result parameter is first in ddl, or perform the same reordering for index metadata. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5128) transaction support value not cloned on access node

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5128?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5128: ---------------------------------- Fix Version/s: 9.3.5 > transaction support value not cloned on access node > --------------------------------------------------- > > Key: TEIID-5128 > URL: https://issues.jboss.org/browse/TEIID-5128 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 10.0, 9.3.5 > > > The transaction support flag is not cloned, which leads non-transactional access to still start a transaction. For example with typical web services lateral join when preformed in a procedure: > begin > select ... from (invokeHttp...) as x, texttable(...); > end > Since the procedure plan is cloned for invocation, the transaction support flag won't be set. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5128) transaction support value not cloned on access node

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5128?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5128. ----------------------------------- Resolution: Done Fixed the clone method. Addressed in 10.0.0 since this was an isolated issue. > transaction support value not cloned on access node > --------------------------------------------------- > > Key: TEIID-5128 > URL: https://issues.jboss.org/browse/TEIID-5128 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 10.0 > > > The transaction support flag is not cloned, which leads non-transactional access to still start a transaction. For example with typical web services lateral join when preformed in a procedure: > begin > select ... from (invokeHttp...) as x, texttable(...); > end > Since the procedure plan is cloned for invocation, the transaction support flag won't be set. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5130) Document/refine behavior of treating result parameter as the first parameter

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-5130?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5130. ----------------------------------- Fix Version/s: 9.3.5 Resolution: Done Added more backward compatibility checks to the ws translator. This commit enforces that the result param must be first in the procedure. This is enforced by the property org.teiid.resultAnyPosition which default to false for 10.0 - which is a narrow breaking change, so it's documented how the legacy behavior can be achieved. For 9.3.x org.teiid.resultAnyPosition defaults to true, to keep the old behavior. > Document/refine behavior of treating result parameter as the first parameter > ---------------------------------------------------------------------------- > > Key: TEIID-5130 > URL: https://issues.jboss.org/browse/TEIID-5130 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.3.5, 10.0 > > > DDL and metadata import make the assumption that the return parameter is the first in the underlying metadata (in part to ensure support of varargs), but we still allowed the result parameter to appear anywhere in the parameter list as to maintain backwards compatibility with legacy/Designer ddl. However in index metadata there is slightly different behavior in that the result parameter remains in it's original position. > We need to clarify this behavior - more documentation, enforce/validate that the result parameter is first in ddl, or perform the same reordering for index metadata. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4895) Determine community requirements for WildFly usage

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4895?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-4895: ---------------------------------- Fix Version/s: 10.x (was: 10.0) > Determine community requirements for WildFly usage > -------------------------------------------------- > > Key: TEIID-4895 > URL: https://issues.jboss.org/browse/TEIID-4895 > Project: Teiid > Issue Type: Task > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 10.x > > > WildFly is typically the runtime for Teiid. However we want feedback from the community on what style of WildFly integration is important: > - The ability to deploy Teiid into a managed WildFly instance/cluster > - The combination Teiid/WildFly artifact > - A layered docker image > - Not full WildFly, just Swarm > - Not needed, just Embedded > Based upon this we can better tune our documentation, downloads, and examples. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4895) Determine community requirements for WildFly usage

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4895?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4895: --------------------------------------- Just wanted to make an update on this issue. Based upon these comments, the downloads, and forums, we will continue to offer the full wildfly options. We will de-emphasize and direct usage of Teiid embedded, and rather promote the WildFly Swarm and Spring Boot runtimes - especially for containerized usage on OpenShift. We should be revamping our Swarm integration soon - once they update to WildFly 11. We will be able to assess then addition design considerations that may allow for creating even smaller runtime footprints. > Determine community requirements for WildFly usage > -------------------------------------------------- > > Key: TEIID-4895 > URL: https://issues.jboss.org/browse/TEIID-4895 > Project: Teiid > Issue Type: Task > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 10.0 > > > WildFly is typically the runtime for Teiid. However we want feedback from the community on what style of WildFly integration is important: > - The ability to deploy Teiid into a managed WildFly instance/cluster > - The combination Teiid/WildFly artifact > - A layered docker image > - Not full WildFly, just Swarm > - Not needed, just Embedded > Based upon this we can better tune our documentation, downloads, and examples. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5130) Document/refine behavior of treating result parameter as the first parameter

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-5130: ------------------------------------- Summary: Document/refine behavior of treating result parameter as the first parameter Key: TEIID-5130 URL: https://issues.jboss.org/browse/TEIID-5130 Project: Teiid Issue Type: Quality Risk Components: Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 10.0 DDL and metadata import make the assumption that the return parameter is the first in the underlying metadata (in part to ensure support of varargs), but we still allowed the result parameter to appear anywhere in the parameter list as to maintain backwards compatibility with legacy/Designer ddl. However in index metadata there is slightly different behavior in that the result parameter remains in it's original position. We need to clarify this behavior - more documentation, enforce/validate that the result parameter is first in ddl, or perform the same reordering for index metadata. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5129) File translator Java 6 issue

by Jan Stastny (JIRA)

Jan Stastny created TEIID-5129: ---------------------------------- Summary: File translator Java 6 issue Key: TEIID-5129 URL: https://issues.jboss.org/browse/TEIID-5129 Project: Teiid Issue Type: Bug Components: Misc. Connectors Affects Versions: 8.12.x-6.4 Reporter: Jan Stastny Assignee: Steven Hawkins Priority: Blocker In file translator (FileExecutionFactory.java) there is usage of java.nio.file.Files and java.nio.file.attribute.FileTime classes, which are since Java 1.7 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5128) transaction support value not cloned on access node

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-5128: ------------------------------------- Summary: transaction support value not cloned on access node Key: TEIID-5128 URL: https://issues.jboss.org/browse/TEIID-5128 Project: Teiid Issue Type: Bug Components: Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 10.0 The transaction support flag is not cloned, which leads non-transactional access to still start a transaction. For example with typical web services lateral join when preformed in a procedure: begin select ... from (invokeHttp...) as x, texttable(...); end Since the procedure plan is cloned for invocation, the transaction support flag won't be set. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues October 2017