March 2016 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-4035) Parameter alias without value returns http status code 500

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4035?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-4035: ------------------------------------- [~jdurani]The comment I meant in general, I see that failing in next version Olingo 4.2.0 where the parsing rules are more strict. > Parameter alias without value returns http status code 500 > ---------------------------------------------------------- > > Key: TEIID-4035 > URL: https://issues.jboss.org/browse/TEIID-4035 > Project: Teiid > Issue Type: Sub-task > Components: OData > Reporter: Juraj Duráni > Assignee: Ramesh Reddy > > *URL:* http://localhost:8080/odata4/olingo_basic/Source/SimpleTableView/?$filter... > *Result:* OData Library: An exception without message text was thrown. > See http://docs.oasis-open.org/odata/odata/v4.0/errata02/os/complete/part1-pr... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (TEIID-4089) Teiid JDBC driver does not reset the update count when calling getMoreResults(int)

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4089?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-4089: ---------------------------------- Issue Type: Bug (was: Feature Request) > Teiid JDBC driver does not reset the update count when calling getMoreResults(int) > ---------------------------------------------------------------------------------- > > Key: TEIID-4089 > URL: https://issues.jboss.org/browse/TEIID-4089 > Project: Teiid > Issue Type: Bug > Components: JDBC Driver > Affects Versions: 8.11.2 > Environment: Windows 7 Pro 64bit > Java 8u66 64bit > Reporter: Jesse Shaffer > Assignee: Steven Hawkins > Fix For: 9.0, 8.12.5, 8.13.3 > > > I have run across a situation with the JDBC driver. Looking at {{StatementImpl.getMoreResults(int)}}, it does not clear the update counts, whereas {{StatementImpl.getMoreResults()}} does. Long story short, this is preventing me from integrating the JDBC driver properly into my application, due to the runtime's (3rd party) handling of statements. It gets stuck in an infinite loop because to close the statement, they call {{StatementImpl.getMoreResults(Statement.CLOSE_CURRENT_RESULT);}}, but then they have a check for a -1 value to be returned from {{getUpdateCount()}} before exiting the loop. In my case, that value is always 1, and thus the infinite loop. > It seems logical to me that {{getMoreResults(int)}} should behave the same as {{getMoreResults()}} seeing as they both always return false, only the latter is the only one that closes the resultset/clearing the update count. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (TEIID-4089) Teiid JDBC driver does not reset the update count when calling getMoreResults(int)

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4089?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-4089. ----------------------------------- Resolution: Done Consolidated the logic in the getMoreResults methods. > Teiid JDBC driver does not reset the update count when calling getMoreResults(int) > ---------------------------------------------------------------------------------- > > Key: TEIID-4089 > URL: https://issues.jboss.org/browse/TEIID-4089 > Project: Teiid > Issue Type: Feature Request > Components: JDBC Driver > Affects Versions: 8.11.2 > Environment: Windows 7 Pro 64bit > Java 8u66 64bit > Reporter: Jesse Shaffer > Assignee: Steven Hawkins > Fix For: 9.0, 8.12.5, 8.13.3 > > > I have run across a situation with the JDBC driver. Looking at {{StatementImpl.getMoreResults(int)}}, it does not clear the update counts, whereas {{StatementImpl.getMoreResults()}} does. Long story short, this is preventing me from integrating the JDBC driver properly into my application, due to the runtime's (3rd party) handling of statements. It gets stuck in an infinite loop because to close the statement, they call {{StatementImpl.getMoreResults(Statement.CLOSE_CURRENT_RESULT);}}, but then they have a check for a -1 value to be returned from {{getUpdateCount()}} before exiting the loop. In my case, that value is always 1, and thus the infinite loop. > It seems logical to me that {{getMoreResults(int)}} should behave the same as {{getMoreResults()}} seeing as they both always return false, only the latter is the only one that closes the resultset/clearing the update count. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (TEIID-3906) OData v4 - definition of OData-Isolation header is either being ignored or is not implemented correctly

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3906?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-3906: ------------------------------------- Yes, as part of the other issues I had to update to a our own version of Olingo to "4.2.0-teiid-1" version. This version is currently in the JBoss Third Party Uploads repository. The official 4.2.0 release will be available by end of March 16. When the official 4.2.0 released we will move to that. > OData v4 - definition of OData-Isolation header is either being ignored or is not implemented correctly > ------------------------------------------------------------------------------------------------------- > > Key: TEIID-3906 > URL: https://issues.jboss.org/browse/TEIID-3906 > Project: Teiid > Issue Type: Sub-task > Components: OData > Affects Versions: 8.12.3 > Environment: Teiid - OData v4 > Reporter: Juraj Duráni > Assignee: Ramesh Reddy > Fix For: 9.0, 8.12.5 > > > Teiid does not process header *OData-Isolation: snapshot* defined in request correctly. > * if service (Teiid) does not support this option it must return error 412 > * if Teiid does supports this option then it is not processed correctly, because modifications made during request are visbile > See http://docs.oasis-open.org/odata/odata/v4.0/errata02/os/complete/part1-pr... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (TEIID-3015) ODATA: Duplicate NavigationProperty name

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3015?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3015: --------------------------------------- Ivan what version are you using? Ramesh does this need to be reopened? > ODATA: Duplicate NavigationProperty name > ---------------------------------------- > > Key: TEIID-3015 > URL: https://issues.jboss.org/browse/TEIID-3015 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.3 > Reporter: Ramesh Reddy > Assignee: Ramesh Reddy > Labels: Beta3 > Fix For: 8.8, 8.7.1 > > > Entity 1: TransferRule > Entity 2: FinancialAccount > TransferRule > - sourceAccount : FinancialAccount > - destination : FinancialAccount > - other attributes > the mapping to this for odata resolves to > <NavigationProperty Name="financialaccount" Relationship="LivingODS.transferrule_destinationfinancial_account_id_fk" FromRole="transferrule" ToRole="financialaccount" /> > <NavigationProperty Name="financialaccount" Relationship="LivingODS.transferrule_sourcefinancial_account_id_fk" FromRole="transferrule" > ToRole="financialaccount" /> > The navigation property name is duplicated with in transfer rule entity. > Hence some of the Odata client see it as ambiguous element > Is there a way to customise the Name to > Name="src_financialaccount" and > Name="dest_financialaccount" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (TEIID-4036) Accumulo translator: NullPointerException on runQuery invocation

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4036?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-4036: ---------------------------------- Fix Version/s: 8.12.5 > Accumulo translator: NullPointerException on runQuery invocation > ---------------------------------------------------------------- > > Key: TEIID-4036 > URL: https://issues.jboss.org/browse/TEIID-4036 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.12.5 > Reporter: Jan Stastny > Assignee: Steven Hawkins > Fix For: 8.12.5 > > Attachments: accumulo-vdb.xml > > > Teiid query on accumulo fails with following exception: > {code:plain} > org.teiid.jdbc.TeiidSQLException: org.teiid.core.TeiidException > at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:135) > at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:71) > at org.teiid.jdbc.StatementImpl.postReceiveResults(StatementImpl.java:706) > at org.teiid.jdbc.StatementImpl.access$100(StatementImpl.java:64) > at org.teiid.jdbc.StatementImpl$2.onCompletion(StatementImpl.java:545) > at org.teiid.client.util.ResultsFuture.done(ResultsFuture.java:135) > at org.teiid.client.util.ResultsFuture.access$200(ResultsFuture.java:40) > at org.teiid.client.util.ResultsFuture$1.receiveResults(ResultsFuture.java:79) > at org.teiid.net.socket.SocketServerInstanceImpl.receivedMessage(SocketServerInstanceImpl.java:268) > at org.teiid.net.socket.SocketServerInstanceImpl.read(SocketServerInstanceImpl.java:306) > at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.teiid.net.socket.SocketServerConnectionFactory$ShutdownHandler.invoke(SocketServerConnectionFactory.java:98) > at com.sun.proxy.$Proxy6.read(Unknown Source) > at org.teiid.net.socket.SocketServerInstanceImpl$RemoteInvocationHandler$1.get(SocketServerInstanceImpl.java:405) > at org.teiid.jdbc.StatementImpl.executeSql(StatementImpl.java:554) > at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:1076) > at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:323) > at org.jboss.bqt.framework.AbstractQuery.execute(AbstractQuery.java:208) > at org.jboss.bqt.client.testcase.ProcessResults.executeTest(ProcessResults.java:280) > at org.jboss.bqt.client.testcase.ProcessResults.runTestCase(ProcessResults.java:160) > at org.jboss.bqt.client.TestClient.runScenario(TestClient.java:209) > at org.jboss.bqt.client.TestClient.runTest(TestClient.java:132) > at org.jboss.bqt.client.TestClient.runTest(TestClient.java:113) > at org.jboss.qe.bqt.BQTHelper.startTest(BQTHelper.java:59) > at org.jboss.dv.test.bqt.Utils.runScenarioTest(Utils.java:197) > at org.jboss.dv.test.bqt.TestPassFour.test(TestPassFour.java:174) > at sun.reflect.GeneratedMethodAccessor47.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291) > at org.testng.SuiteRunner.run(SuiteRunner.java:240) > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1198) > at org.testng.TestNG.runSuitesLocally(TestNG.java:1123) > at org.testng.TestNG.run(TestNG.java:1031) > at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:70) > at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:108) > at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:111) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:172) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:104) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70) > Caused by: org.teiid.core.TeiidException > at org.teiid.client.ResultsMessage.setException(ResultsMessage.java:196) > at org.teiid.dqp.internal.process.RequestWorkItem.sendError(RequestWorkItem.java:1084) > at org.teiid.dqp.internal.process.RequestWorkItem.close(RequestWorkItem.java:576) > at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:374) > at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) > at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:274) > at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276) > at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) > at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NullPointerException > at org.apache.accumulo.core.client.impl.Namespaces.getMap(Namespaces.java:98) > at org.apache.accumulo.core.client.impl.Namespaces.getNameToIdMap(Namespaces.java:131) > at org.apache.accumulo.core.client.impl.Tables._getTableId(Tables.java:183) > at org.apache.accumulo.core.client.impl.Tables.getTableId(Tables.java:169) > at org.apache.accumulo.core.client.impl.ConnectorImpl.getTableId(ConnectorImpl.java:80) > at org.apache.accumulo.core.client.impl.ConnectorImpl.createScanner(ConnectorImpl.java:147) > at org.teiid.translator.accumulo.AccumuloQueryExecution.runQuery(AccumuloQueryExecution.java:99) > at org.teiid.translator.accumulo.AccumuloQueryExecution.execute(AccumuloQueryExecution.java:84) > at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:359) > at sun.reflect.GeneratedMethodAccessor418.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211) > at com.sun.proxy.$Proxy159.execute(Unknown Source) > at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:306) > at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:112) > at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65) > ... 6 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (TEIID-3906) OData v4 - definition of OData-Isolation header is either being ignored or is not implemented correctly

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-3906?page=com.atlassian.jira.plugin... ] Van Halbert commented on TEIID-3906: ------------------------------------ With this being resolved, is it assumed that Teiid will now require Olingo 4.2.0? > OData v4 - definition of OData-Isolation header is either being ignored or is not implemented correctly > ------------------------------------------------------------------------------------------------------- > > Key: TEIID-3906 > URL: https://issues.jboss.org/browse/TEIID-3906 > Project: Teiid > Issue Type: Sub-task > Components: OData > Affects Versions: 8.12.3 > Environment: Teiid - OData v4 > Reporter: Juraj Duráni > Assignee: Ramesh Reddy > Fix For: 9.0, 8.12.5 > > > Teiid does not process header *OData-Isolation: snapshot* defined in request correctly. > * if service (Teiid) does not support this option it must return error 412 > * if Teiid does supports this option then it is not processed correctly, because modifications made during request are visbile > See http://docs.oasis-open.org/odata/odata/v4.0/errata02/os/complete/part1-pr... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (TEIID-4047) OData - $top with negative value return status code 500

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4047?page=com.atlassian.jira.plugin... ] Ramesh Reddy resolved TEIID-4047. --------------------------------- Fix Version/s: 9.0 8.12.5 Resolution: Done Resolving for this particular issue, the general error processing can be done as part of other JIRAs. Steve use TEIID-3911 or others to refine the behavior > OData - $top with negative value return status code 500 > ------------------------------------------------------- > > Key: TEIID-4047 > URL: https://issues.jboss.org/browse/TEIID-4047 > Project: Teiid > Issue Type: Sub-task > Components: OData > Reporter: Juraj Duráni > Assignee: Ramesh Reddy > Fix For: 9.0, 8.12.5 > > > OData request with query option $top with negative value returns status code 500. The root cause is SQLException. OData service should check passed value and return e.g. 400 instead. > *URL:* http://localhost:8080/odata4/olingo_basic/Source/Customers/?$top=-1 > See http://docs.oasis-open.org/odata/odata/v4.0/errata02/os/complete/part1-pr... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (TEIID-4041) OData response does not contain header "allow"

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4041?page=com.atlassian.jira.plugin... ] Ramesh Reddy resolved TEIID-4041. --------------------------------- Resolution: Done Changed upstream ServiceDispatcher logic to send the "Allow" header when 405 is being send to the client > OData response does not contain header "allow" > ---------------------------------------------- > > Key: TEIID-4041 > URL: https://issues.jboss.org/browse/TEIID-4041 > Project: Teiid > Issue Type: Sub-task > Components: OData > Reporter: Juraj Duráni > Assignee: Ramesh Reddy > > If user sends request to URL with unsupported HTTP method, OData service should return allowed methods in header _allow_. > *URL:* http://localhost:8080/odata4/olingo_basic/Source/SimpleTableView/ > *Method:* DELETE > *Response headers:* date=Wed, 09 Mar 2016 08:21:17 GMT, server=Apache-Coyote/1.1, content-length=192, expires=Thu, 01 Jan 1970 00:00:00 GMT+00:00, content-type=application/xml, cache-control=no-cache, pragma=No-cache, odata-version=4.0 > See http://docs.oasis-open.org/odata/odata/v4.0/errata02/os/complete/part1-pr... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (TEIID-3906) OData v4 - definition of OData-Isolation header is either being ignored or is not implemented correctly

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-3906?page=com.atlassian.jira.plugin... ] Ramesh Reddy resolved TEIID-3906. --------------------------------- Resolution: Done > OData v4 - definition of OData-Isolation header is either being ignored or is not implemented correctly > ------------------------------------------------------------------------------------------------------- > > Key: TEIID-3906 > URL: https://issues.jboss.org/browse/TEIID-3906 > Project: Teiid > Issue Type: Sub-task > Components: OData > Affects Versions: 8.12.3 > Environment: Teiid - OData v4 > Reporter: Juraj Duráni > Assignee: Ramesh Reddy > Fix For: 9.0, 8.12.5 > > > Teiid does not process header *OData-Isolation: snapshot* defined in request correctly. > * if service (Teiid) does not support this option it must return error 412 > * if Teiid does supports this option then it is not processed correctly, because modifications made during request are visbile > See http://docs.oasis-open.org/odata/odata/v4.0/errata02/os/complete/part1-pr... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues March 2016