November 2015 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-3789) Enable setting on SOLR translator for controlling timezone setting for Date and Timestamp columns

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3789?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3789: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1275335|https://bugzilla.redhat.com/show_bug.cgi?id=1275335] from NEW to CLOSED > Enable setting on SOLR translator for controlling timezone setting for Date and Timestamp columns > ------------------------------------------------------------------------------------------------- > > Key: TEIID-3789 > URL: https://issues.jboss.org/browse/TEIID-3789 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Affects Versions: 8.7.1 > Reporter: Van Halbert > > Timezone of DV server has influence on Date and Timestamp columns in some data sources -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-3815) Oracle translator - OFFSET function does not work

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3815?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3815: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1279460|https://bugzilla.redhat.com/show_bug.cgi?id=1279460] from NEW to MODIFIED > Oracle translator - OFFSET function does not work > ------------------------------------------------- > > Key: TEIID-3815 > URL: https://issues.jboss.org/browse/TEIID-3815 > Project: Teiid > Issue Type: Bug > Affects Versions: 8.7.2.6_2 > Reporter: Juraj Duráni > Assignee: Steven Hawkins > Fix For: 8.12.2, 8.13 > > > Oracle translator translates OFFSET function as: > {code:sql} > SELECT c_0 FROM (SELECT VIEW_FOR_LIMIT.*, ROWNUM ROWNUM_ FROM (***Query***) VIEW_FOR_LIMIT WHERE ROWNUM <= -2147483604) WHERE ROWNUM_ > 45 > {code} > This always returns an empty result because of *ROWNUM <= -2147483604*. > Example: > Query: > {code:sql} > SELECT INTKEY FROM bqt1.smalla ORDER BY INTKEY OFFSET 45 ROWS > {code} > Source-specific command: > {code:sql} > SELECT c_0 FROM (SELECT VIEW_FOR_LIMIT.*, ROWNUM ROWNUM_ FROM (SELECT trunc(g_0."INTKEY") AS c_0 FROM "DV"."SMALLA" g_0 ORDER BY c_0) VIEW_FOR_LIMIT WHERE ROWNUM <= -2147483604) WHERE ROWNUM_ > 45 > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-3462) Add support for semantic versioning of VDBs

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3462?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3462: --------------------------------------- > Change the version field to a string rather than an integer, and allow for the break in backwards compatibility. While logically straight-forward as I work through it this is a massive change affecting 60+ classes and will break more apis than I had anticipated. An alternative would be to use a property / file name to indicate the semantic version and to start by simply deprecating the old version field and using the vdb name to convey the fully versioned name when appropriate. > Add support for semantic versioning of VDBs > ------------------------------------------- > > Key: TEIID-3462 > URL: https://issues.jboss.org/browse/TEIID-3462 > Project: Teiid > Issue Type: Feature Request > Components: Server > Affects Versions: 8.7 > Reporter: Marc Shirley > Assignee: Steven Hawkins > Fix For: 9.0 > > > Semantic versioning [1] should be supported in the VDB versioning in order to be able to easier determine whether there are breaking changes from the client perspective and to more easily establish a link between client software versions and the VDBs they rely upon. > [1] http://semver.org/ -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-3825) Add a wildfly-swarm-teiid Fraction for running teiid as an uberjar

by Kylin Soong (JIRA)

Kylin Soong created TEIID-3825: ---------------------------------- Summary: Add a wildfly-swarm-teiid Fraction for running teiid as an uberjar Key: TEIID-3825 URL: https://issues.jboss.org/browse/TEIID-3825 Project: Teiid Issue Type: Feature Request Components: Embedded Affects Versions: 9.0 Reporter: Kylin Soong Assignee: Kylin Soong Fix For: 9.x Fractions within WildFly Swarm are roughly equivalent to subsystems within WildFly, we have teiid subsystem in Server mode, so I think a Fraction is necessary to run teiid with Swarm. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-3811) Teiid Embedded with remote JDBC susceptible to exploit with common-collections in classpath

by Gary Gregory (JIRA)

[ https://issues.jboss.org/browse/TEIID-3811?page=com.atlassian.jira.plugin... ] Gary Gregory commented on TEIID-3811: ------------------------------------- Note that we (Apache Commons) are in the middle of cutting a 3.2.2 version to address this security vulnerability. > Teiid Embedded with remote JDBC susceptible to exploit with common-collections in classpath > ------------------------------------------------------------------------------------------- > > Key: TEIID-3811 > URL: https://issues.jboss.org/browse/TEIID-3811 > Project: Teiid > Issue Type: Quality Risk > Components: Embedded > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Critical > Fix For: 8.12.2, 8.13 > > > This issue is to add at least a documentation note warning against - http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-j... > While remote JDBC is not enabled by default and common-collections is not in the classpath it is possible that common-collections could be picked up from the environment. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-3462) Add support for semantic versioning of VDBs

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3462?page=com.atlassian.jira.plugin... ] Steven Hawkins edited comment on TEIID-3462 at 11/13/15 2:10 PM: ----------------------------------------------------------------- The approaches for this look like: - Change the version field to a string rather than an integer, and allow for the break in backwards compatibility. - Add major/minor/micro version as fields and deprecate the version integer (make it just the major version) and try to retain some compatibility. Although we would need to add duplicate admin methods ect. to allow for the full version to be specified. - Use a property to drive whether the version is encoded for example 10 bits for each part with some alternative logic for displaying the version. The first is by far the simplest and the reason for pushing this to 9.0, but if anyone wants to make the case for a more backwards compatibly scenario, let me know. was (Author: shawkins): The approaches for this look like: -Change the version field to a string rather than an integer, and allow for the break in backwards compatibility. - Add major/minor/micro version as fields and deprecate the version integer (make it just the major version) and try to retain some compatibility. Although we would need to add duplicate admin methods ect. to allow for the full version to be specified. - Use a property to drive whether the version is encoded for example 10 bits for each part with some alternative logic for displaying the version. The first is by far the simplest and the reason for pushing this to 9.0, but if anyone wants to make the case for a more backwards compatibly scenario, let me know. > Add support for semantic versioning of VDBs > ------------------------------------------- > > Key: TEIID-3462 > URL: https://issues.jboss.org/browse/TEIID-3462 > Project: Teiid > Issue Type: Feature Request > Components: Server > Affects Versions: 8.7 > Reporter: Marc Shirley > Assignee: Steven Hawkins > Fix For: 9.0 > > > Semantic versioning [1] should be supported in the VDB versioning in order to be able to easier determine whether there are breaking changes from the client perspective and to more easily establish a link between client software versions and the VDBs they rely upon. > [1] http://semver.org/ -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-3462) Add support for semantic versioning of VDBs

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3462?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3462: --------------------------------------- The approaches for this look like: -Change the version field to a string rather than an integer, and allow for the break in backwards compatibility. - Add major/minor/micro version as fields and deprecate the version integer (make it just the major version) and try to retain some compatibility. Although we would need to add duplicate admin methods ect. to allow for the full version to be specified. - Use a property to drive whether the version is encoded for example 10 bits for each part with some alternative logic for displaying the version. The first is by far the simplest and the reason for pushing this to 9.0, but if anyone wants to make the case for a more backwards compatibly scenario, let me know. > Add support for semantic versioning of VDBs > ------------------------------------------- > > Key: TEIID-3462 > URL: https://issues.jboss.org/browse/TEIID-3462 > Project: Teiid > Issue Type: Feature Request > Components: Server > Affects Versions: 8.7 > Reporter: Marc Shirley > Assignee: Steven Hawkins > Fix For: 9.0 > > > Semantic versioning [1] should be supported in the VDB versioning in order to be able to easier determine whether there are breaking changes from the client perspective and to more easily establish a link between client software versions and the VDBs they rely upon. > [1] http://semver.org/ -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-3824) Asynch connector work item close

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3824?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-3824. ----------------------------------- Fix Version/s: 8.12.2 8.13 Resolution: Done Modified the logic to allow the asynch thread to call close and to prevent the engine thread from waiting if possible. > Asynch connector work item close > -------------------------------- > > Key: TEIID-3824 > URL: https://issues.jboss.org/browse/TEIID-3824 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.12.2, 8.13 > > > Related to TEIID-3612 we need to improve how close is called on the connector work item. Since the work item will always be done it's likely that the processing thread will call close while the workitem lock is held and hold up the processing thread unnecessarily. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-3824) Asynch connector work item close

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-3824: ------------------------------------- Summary: Asynch connector work item close Key: TEIID-3824 URL: https://issues.jboss.org/browse/TEIID-3824 Project: Teiid Issue Type: Quality Risk Components: Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins Related to TEIID-3612 we need to improve how close is called on the connector work item. Since the work item will always be done it's likely that the processing thread will call close while the workitem lock is held and hold up the processing thread unnecessarily. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (TEIID-3823) Issues with fetchsize and local connections

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3823?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-3823. ----------------------------------- Resolution: Done Added a check to prevent more processing when there is no request and correctly saving the partially returned batch. > Issues with fetchsize and local connections > ------------------------------------------- > > Key: TEIID-3823 > URL: https://issues.jboss.org/browse/TEIID-3823 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.13, 8.12.3 > > > Settting the fetchSize property on localconnections (or if the internal batch size exceeds that of the maximum fetch size, which is unlikely by default) leads to several issues: > It can cause an exception or the client may seem to hang (since the logic won't properly save the current batch). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 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 November 2015