July 2016 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-4228) ODBC "Parse Statements" option can result in changes in LENGTH metadata for columns

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4228?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-4228: ---------------------------------- Fix Version/s: 9.1 (was: 9.x) > ODBC "Parse Statements" option can result in changes in LENGTH metadata for columns > ----------------------------------------------------------------------------------- > > Key: TEIID-4228 > URL: https://issues.jboss.org/browse/TEIID-4228 > Project: Teiid > Issue Type: Bug > Components: ODBC > Affects Versions: 8.7 > Environment: Connections through ODBC driver > Reporter: Marc Shirley > Assignee: Steven Hawkins > Priority: Minor > Fix For: 9.1 > > > Connections through ODBC driver with the driver setting "Parse Statements" option enabled can result in incorrect length values being passed to the client. In some cases (such as SQL Server linked server capabilities), this can result in the client throwing exceptions due to the expected LENGTH changing during the course of the query execution. > This may be limited to columns with precision set to 0, as the SQL Server linked server case was corrected when the precision was changed from 0 to 9 for the column specified in the error. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4278) MySQL 5 should support distinct aggregates

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-4278?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-4278: --------------------------------- Fix Version/s: 8.7.8.6_2 > MySQL 5 should support distinct aggregates > ------------------------------------------ > > Key: TEIID-4278 > URL: https://issues.jboss.org/browse/TEIID-4278 > Project: Teiid > Issue Type: Enhancement > Components: JDBC Connector > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.1, 8.7.8.6_2 > > > Older versions of mysql only supported distinct count, but later versions supported distinct with all relevant aggregates. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4278) MySQL 5 should support distinct aggregates

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-4278?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-4278: ------------------------------------------------ jolee(a)redhat.com changed the Status of [bug 1349560|https://bugzilla.redhat.com/show_bug.cgi?id=1349560] from NEW to MODIFIED > MySQL 5 should support distinct aggregates > ------------------------------------------ > > Key: TEIID-4278 > URL: https://issues.jboss.org/browse/TEIID-4278 > Project: Teiid > Issue Type: Enhancement > Components: JDBC Connector > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.1, 8.7.8.6_2 > > > Older versions of mysql only supported distinct count, but later versions supported distinct with all relevant aggregates. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4245) Add support for fetch syntax "FETCH cursorname"

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-4245?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-4245: --------------------------------- Fix Version/s: 8.7.8.6_2 > Add support for fetch syntax "FETCH cursorname" > ----------------------------------------------- > > Key: TEIID-4245 > URL: https://issues.jboss.org/browse/TEIID-4245 > Project: Teiid > Issue Type: Feature Request > Components: ODBC > Reporter: Marc Shirley > Assignee: Steven Hawkins > Fix For: 9.1, 8.7.8.6_2 > > > Executing syntax "FETCH cursorname" results in parsing error like [1]. Instead, syntax like "FETCH 1 IN cursorname" has been used as a workaround. > [1] > org.teiid.api.exception.query.QueryParserException: TEIID31100 Parsing error: Encountered "[*]FETCH[*] mycursor" at line 1, column 1. > Was expecting: "alter" | "begin" | "call" | "create" | "delete" | "drop" | "exec" | "execute" | "insert" | "merge" ... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4316) Accumulo translator: null values not returned for <> criteria in WHERE clause

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-4316?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-4316: ------------------------------------------------ Van Halbert <vhalbert(a)redhat.com> changed the Status of [bug 1351987|https://bugzilla.redhat.com/show_bug.cgi?id=1351987] from NEW to CLOSED > Accumulo translator: null values not returned for <> criteria in WHERE clause > ----------------------------------------------------------------------------- > > Key: TEIID-4316 > URL: https://issues.jboss.org/browse/TEIID-4316 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.12.5 > Reporter: Jan Stastny > Assignee: Ramesh Reddy > > For columns, which contain some null values, a query like: > {code:sql} > SELECT nullable_column FROM table_name WHERE nullable_column <> some_value > {code} > doesn't return null values. > Simple select works: > {code:sql} > SELECT nullable_column FROM table_name > {code} > returns all rows regardless whether they are null or not. > IS NULL criteria in WHERE clause also work: > {code:sql} > SELECT nullable_column FROM table_name WHERE nullable_column IS NULL > {code} > returns correct number of null values. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4316) Accumulo translator: null values not returned for <> criteria in WHERE clause

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4316?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-4316. ----------------------------------- Resolution: Rejected Almost all sources should support three-valued null logic. As Ramesh is showing with Postgresql, a comparison with null will evaluate to unknown, which will not pass as true in a where clause, thus no null rows. > Accumulo translator: null values not returned for <> criteria in WHERE clause > ----------------------------------------------------------------------------- > > Key: TEIID-4316 > URL: https://issues.jboss.org/browse/TEIID-4316 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.12.5 > Reporter: Jan Stastny > Assignee: Ramesh Reddy > > For columns, which contain some null values, a query like: > {code:sql} > SELECT nullable_column FROM table_name WHERE nullable_column <> some_value > {code} > doesn't return null values. > Simple select works: > {code:sql} > SELECT nullable_column FROM table_name > {code} > returns all rows regardless whether they are null or not. > IS NULL criteria in WHERE clause also work: > {code:sql} > SELECT nullable_column FROM table_name WHERE nullable_column IS NULL > {code} > returns correct number of null values. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4319) Deprecate automatically adding of the class object to the source table

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4319?page=com.atlassian.jira.plugin... ] Van Halbert updated TEIID-4319: ------------------------------- Description: If the source model is not defined with the metadata, but allowing the infinispan (object) translator to reverse engineer the metadata from the cache object class, the process will add a column that represents the cache object. This is a holdover from the original implementation that used the OBJECTTABLE function for transforming the object into a row in the result set. This column is not required and can be excluded (or removed) if modeling the object source table. This column also causes WARNING to show up in the server log because it is assumed by the engine to be part of materialization. However, this column is not updatable and can be excluded in materialization by not specifying it in the INSERT INTO statement. So to clean up all this, it would be good to stop adding the class object as a column in the source table. And the user can always add it back if they wish to use it. was: If allowing the infinispan (object) translator to reverse engineer the metadata from the cache object class, the process will add a column that represents the cache object. This is a holdover from the original implementation that used the OBJECTTABLE function for transforming the object into a row in the result set. This column is not required and can be excluded (or removed) if modeling the object source table. This column also causes WARNING to show up in the server log because it is assumed by the engine to be part of materialization. However, this column is not updatable and can be excluded in materialization by not specifying it in the INSERT INTO statement. So to clean up all this, it would be good to stop adding the class object as a column in the source table. And the user can always add it back if they wish to use it. > Deprecate automatically adding of the class object to the source table > ---------------------------------------------------------------------- > > Key: TEIID-4319 > URL: https://issues.jboss.org/browse/TEIID-4319 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Affects Versions: 9.x > Reporter: Van Halbert > Assignee: Van Halbert > > If the source model is not defined with the metadata, but allowing the infinispan (object) translator to reverse engineer the metadata from the cache object class, the process will add a column that represents the cache object. This is a holdover from the original implementation that used the OBJECTTABLE function for transforming the object into a row in the result set. This column is not required and can be excluded (or removed) if modeling the object source table. > This column also causes WARNING to show up in the server log because it is assumed by the engine to be part of materialization. However, this column is not updatable and can be excluded in materialization by not specifying it in the INSERT INTO statement. > So to clean up all this, it would be good to stop adding the class object as a column in the source table. And the user can always add it back if they wish to use it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4319) Deprecate automatically adding of the class object to the source table

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4319?page=com.atlassian.jira.plugin... ] Van Halbert updated TEIID-4319: ------------------------------- Summary: Deprecate automatically adding of the class object to the source table (was: Deprecate the automatically adding of the class object to the source table) > Deprecate automatically adding of the class object to the source table > ---------------------------------------------------------------------- > > Key: TEIID-4319 > URL: https://issues.jboss.org/browse/TEIID-4319 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Affects Versions: 9.x > Reporter: Van Halbert > Assignee: Van Halbert > > If allowing the infinispan (object) translator to reverse engineer the metadata from the cache object class, the process will add a column that represents the cache object. This is a holdover from the original implementation that used the OBJECTTABLE function for transforming the object into a row in the result set. This column is not required and can be excluded (or removed) if modeling the object source table. > This column also causes WARNING to show up in the server log because it is assumed by the engine to be part of materialization. However, this column is not updatable and can be excluded in materialization by not specifying it in the INSERT INTO statement. > So to clean up all this, it would be good to stop adding the class object as a column in the source table. And the user can always add it back if they wish to use it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4319) Deprecate the automatically adding of the class object to the source table

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-4319?page=com.atlassian.jira.plugin... ] Van Halbert reassigned TEIID-4319: ---------------------------------- Assignee: Van Halbert (was: Steven Hawkins) > Deprecate the automatically adding of the class object to the source table > -------------------------------------------------------------------------- > > Key: TEIID-4319 > URL: https://issues.jboss.org/browse/TEIID-4319 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Affects Versions: 9.x > Reporter: Van Halbert > Assignee: Van Halbert > > If allowing the infinispan (object) translator to reverse engineer the metadata from the cache object class, the process will add a column that represents the cache object. This is a holdover from the original implementation that used the OBJECTTABLE function for transforming the object into a row in the result set. This column is not required and can be excluded (or removed) if modeling the object source table. > This column also causes WARNING to show up in the server log because it is assumed by the engine to be part of materialization. However, this column is not updatable and can be excluded in materialization by not specifying it in the INSERT INTO statement. > So to clean up all this, it would be good to stop adding the class object as a column in the source table. And the user can always add it back if they wish to use it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4319) Deprecate the automatically adding of the class object to the source table

by Van Halbert (JIRA)

Van Halbert created TEIID-4319: ---------------------------------- Summary: Deprecate the automatically adding of the class object to the source table Key: TEIID-4319 URL: https://issues.jboss.org/browse/TEIID-4319 Project: Teiid Issue Type: Enhancement Components: Misc. Connectors Affects Versions: 9.x Reporter: Van Halbert Assignee: Steven Hawkins If allowing the infinispan (object) translator to reverse engineer the metadata from the cache object class, the process will add a column that represents the cache object. This is a holdover from the original implementation that used the OBJECTTABLE function for transforming the object into a row in the result set. This column is not required and can be excluded (or removed) if modeling the object source table. This column also causes WARNING to show up in the server log because it is assumed by the engine to be part of materialization. However, this column is not updatable and can be excluded in materialization by not specifying it in the INSERT INTO statement. So to clean up all this, it would be good to stop adding the class object as a column in the source table. And the user can always add it back if they wish to use it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues July 2016