June 2016 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-4247) OData - support date and time functions

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4247?page=com.atlassian.jira.plugin... ] Ramesh Reddy resolved TEIID-4247. --------------------------------- Resolution: Done > OData - support date and time functions > --------------------------------------- > > Key: TEIID-4247 > URL: https://issues.jboss.org/browse/TEIID-4247 > Project: Teiid > Issue Type: Feature Request > Components: OData > Affects Versions: 8.12.x > Reporter: Andrej Šmigala > Assignee: Ramesh Reddy > Fix For: 9.1 > > > The functions date() and time() are currently not supported in odata queries, e.g. running query {noformat}http://localhost:8080/odata4/olingo_basic/Source/SimpleDataTable?$filter=timeval%20gt%20time(now()){noformat} > returns {code:xml} > <?xml version='1.0' encoding='UTF-8'?> > <error xmlns="http://docs.oasis-open.org/odata/ns/metadata"> > <code>TEIID16027</code> > <message>TEIID16027 Function time is not currently supported </message> > </error> > {code} > This is allowed behaviour per the [odata spec|http://docs.oasis-open.org/odata/odata/v4.0/errata02/os/complete/par...], but it would be good to have these functions implemented. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

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

by Steve Tran (JIRA)

[ https://issues.jboss.org/browse/TEIID-4228?page=com.atlassian.jira.plugin... ] Steve Tran commented on TEIID-4228: ----------------------------------- Teiid datatype of this column is bigdecimal:xs:decimal. Source database is SQL Server for this particular table. Similar issues discovered for an Oracle backed table as well. Metadata created via JDBC Importer via Teiid Designer 9.0.6 > 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.x > > > 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)

9 years, 9 months

1
0
0 / 0

[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 commented on TEIID-4228: --------------------------------------- > Scratch that, I'm seeing this issue on a numeric field that has the following: Just to validate the metadata - what is the teiid type of the column, what is the source database, and how was the metadata entry created designer import, or teiid? > 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.x > > > 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)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4148) Add "org.modeshape.jdbc" dependency to teiid jdbc translator module

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4148?page=com.atlassian.jira.plugin... ] Steven Hawkins closed TEIID-4148. --------------------------------- > Add "org.modeshape.jdbc" dependency to teiid jdbc translator module > ------------------------------------------------------------------- > > Key: TEIID-4148 > URL: https://issues.jboss.org/browse/TEIID-4148 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 8.12.5 > Reporter: Van Halbert > Assignee: Van Halbert > Fix For: 9.0, 8.12.5 > > > the "org.jboss.teiid.translator.jdbc" module (where the query originates from) has to list "org.modeshape.jdbc" as a dependency so that ModeShape's CP can be accessible. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4183) MSSQL JDBC driver invalidates kerberos ticket on Connection.close()

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4183?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-4183: ------------------------------------- on (1) They must be using "connectionPoolBySubject", they did that in EAP 5, but since then I thought they moved past that. Either case caching is preferred. Is there a way to invalidate the cache? (3) with code change I think this exception is gone now. (5) yes, you can use single passthrough for any kind, unless user at top level used kerberos then kerberos specific code kicks in. - Another good test case may be, using two users and limit the pool to two connections and interleave them and make sure we are not accidentally using subject one from the other > MSSQL JDBC driver invalidates kerberos ticket on Connection.close() > ------------------------------------------------------------------- > > Key: TEIID-4183 > URL: https://issues.jboss.org/browse/TEIID-4183 > Project: Teiid > Issue Type: Bug > Affects Versions: 8.12.x, 8.7.5.6_2 > Reporter: Juraj Duráni > Assignee: Ramesh Reddy > Fix For: 9.1, 8.12.5 > > > MSSQL JDBC driver invalidate kerberos ticket on Connection.close() (related bugzilla \[1\]). > If user creates kerberos connection, driver invalidates ticket on closing connection (Connection.close()). Therefore ticket cannot be re-used. EAP team creates a workaround for this by adding module option *wrapGSSCredential=true* with additional setting *credentialLifetime=-1* \[2, 3, 4, 5\]. This works for static kerberos authentication. > However, passthrough authentication (org.teiid.jboss.PassthroughIdentityLoginModule) does not work, because passed ticket is not managed by EAP but by client. > \[1\] https://bugzilla.redhat.com/show_bug.cgi?id=1097276 > \[2\] https://bugzilla.redhat.com/show_bug.cgi?id=1097276#c58 > \[3\] https://issues.jboss.org/browse/SECURITY-905 > \[4\] https://issues.jboss.org/browse/JBEAP-843 > \[5\] https://github.com/wildfly-security/jboss-negotiation/commit/0c7e06f58a79... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4308) runtime build unit test dump lots of log and error trace

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4308?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4308: --------------------------------------- > INFO: START USER COMMAND:... These logs are from TEIID-3594 which was a product request to allow user commands to be logged at a distinct level vs. src logs. So now we have the levels user=info, src=debug, and plan=trace If your system logs info by default, then you'll see these on the console. > org.infinispan.IllegalLifecycleStateException I believe these are occurring since the change to have pg materialized views proactively created - TEIID-4122 The background queries are not being killed in such a way as to not have a log entry. > runtime build unit test dump lots of log and error trace > -------------------------------------------------------- > > Key: TEIID-4308 > URL: https://issues.jboss.org/browse/TEIID-4308 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Affects Versions: 9.1 > Reporter: Kylin Soong > Assignee: Steven Hawkins > Priority: Optional > > runtime build unit test dump lots of log and error trace, it looks > {code} > Jun 29, 2016 7:52:15 PM org.teiid.runtime.JBossLogger log > INFO: START USER COMMAND:... > org.infinispan.IllegalLifecycleStateException: ISPN000323: Cache 'preparedplan' is in 'TERMINATED' state and so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:94) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76) > at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336) > at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411) > at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:443) > at org.teiid.cache.infinispan.InfinispanCache.get(InfinispanCache.java:61) > at org.teiid.dqp.internal.process.SessionAwareCache.get(SessionAwareCache.java:100) > {code} > In previous 8.x, i remembered no this kinds of log. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

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

by Steve Tran (JIRA)

[ https://issues.jboss.org/browse/TEIID-4228?page=com.atlassian.jira.plugin... ] Steve Tran commented on TEIID-4228: ----------------------------------- Also worth nothing that this is only an issue with SQL Server Linked Servers. If I use another ODBC tool such as RazorSQL or QueryTool (tested with x64), it works fine. > 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.x > > > 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)

9 years, 9 months

1
0
0 / 0

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

by Steve Tran (JIRA)

[ https://issues.jboss.org/browse/TEIID-4228?page=com.atlassian.jira.plugin... ] Steve Tran edited comment on TEIID-4228 at 6/29/16 9:37 AM: ------------------------------------------------------------ --I've encountered this issue on columns that have non-zero precision as well.-- Scratch that, I'm seeing this issue on a numeric field that has the following: Length 9 Length Fixed true Numeric Precision 0 Numeric Scale 0 was (Author: sqtran): I've encountered this issue on columns that have non-zero precision as well. > 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.x > > > 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)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-4308) runtime build unit test dump lots of log and error trace

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4308?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-4308: ---------------------------------- Priority: Optional (was: Major) > runtime build unit test dump lots of log and error trace > -------------------------------------------------------- > > Key: TEIID-4308 > URL: https://issues.jboss.org/browse/TEIID-4308 > Project: Teiid > Issue Type: Quality Risk > Components: Query Engine > Affects Versions: 9.1 > Reporter: Kylin Soong > Assignee: Steven Hawkins > Priority: Optional > > runtime build unit test dump lots of log and error trace, it looks > {code} > Jun 29, 2016 7:52:15 PM org.teiid.runtime.JBossLogger log > INFO: START USER COMMAND:... > org.infinispan.IllegalLifecycleStateException: ISPN000323: Cache 'preparedplan' is in 'TERMINATED' state and so it does not accept new invocations. Either restart it or recreate the cache container. > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:94) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76) > at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336) > at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411) > at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:443) > at org.teiid.cache.infinispan.InfinispanCache.get(InfinispanCache.java:61) > at org.teiid.dqp.internal.process.SessionAwareCache.get(SessionAwareCache.java:100) > {code} > In previous 8.x, i remembered no this kinds of log. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

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

by Steve Tran (JIRA)

[ https://issues.jboss.org/browse/TEIID-4228?page=com.atlassian.jira.plugin... ] Steve Tran commented on TEIID-4228: ----------------------------------- I've encountered this issue on columns that have non-zero precision as well. > 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.x > > > 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)

9 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues June 2016