[JBoss JIRA] (TEIID-3429) Provide hooks to interrogate metadata prior to full import
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3429?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3429:
---------------------------------------
After several discussion with Barrry it's not clear what we're doing in this regard yet. It could be that future tooling will still be responsible for metadata browsing, but will just delegate to Teiid to perform the full import.
> Provide hooks to interrogate metadata prior to full import
> -----------------------------------------------------------
>
> Key: TEIID-3429
> URL: https://issues.jboss.org/browse/TEIID-3429
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.0
>
>
> To support the Desinger we should offer the ability to interrogate metadata prior to full import.
> Exploring metadata is effectively an entirely different mode of operation with respect to the current metadata processing logic on the Teiid side. Also partial metadata isn't something that would neatly be expressed through DDL - tables without columns, a list of schema names, etc.
> Ways around that would be to expose source procedures for metadata interrogation:
>
> getTableNames - which would probably give both the Teiid name and the name in source and consider the current translator metadata settings
> getProcedureNames
> And importer specific info such as for JDBC getTableTypes, getCatalogNames, getSchemaNames
>
> I'd want to keep it fairly high level though. Getting column or key information I'd expect would be done through the normal full import.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (TEIID-3429) Provide hooks to interrogate metadata prior to full import
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3429?page=com.atlassian.jira.plugin... ]
Work on TEIID-3429 stopped by Steven Hawkins.
---------------------------------------------
> Provide hooks to interrogate metadata prior to full import
> -----------------------------------------------------------
>
> Key: TEIID-3429
> URL: https://issues.jboss.org/browse/TEIID-3429
> Project: Teiid
> Issue Type: Feature Request
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 9.0
>
>
> To support the Desinger we should offer the ability to interrogate metadata prior to full import.
> Exploring metadata is effectively an entirely different mode of operation with respect to the current metadata processing logic on the Teiid side. Also partial metadata isn't something that would neatly be expressed through DDL - tables without columns, a list of schema names, etc.
> Ways around that would be to expose source procedures for metadata interrogation:
>
> getTableNames - which would probably give both the Teiid name and the name in source and consider the current translator metadata settings
> getProcedureNames
> And importer specific info such as for JDBC getTableTypes, getCatalogNames, getSchemaNames
>
> I'd want to keep it fairly high level though. Getting column or key information I'd expect would be done through the normal full import.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[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 reassigned TEIID-4036:
-------------------------------------
Assignee: (was: Steven Hawkins)
> 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
> 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)
8 years
[JBoss JIRA] (TEIID-4175) Certain nested dependent join structure will cause fewer results than expected
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-4175?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-4175:
---------------------------------
Fix Version/s: 8.7.6.6_2
> Certain nested dependent join structure will cause fewer results than expected
> ------------------------------------------------------------------------------
>
> Key: TEIID-4175
> URL: https://issues.jboss.org/browse/TEIID-4175
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Blocker
> Fix For: 9.0, 8.12.5, 8.7.6.6_2, 8.13.5
>
>
> With a query such as:
> {code}
> SELECT pm1.g1.e1, pm1.g2.e2 from /*+ makeind */ pm1.g1 inner join /*+ preserve */ (/*+ makeind */ pm1.g2 inner join pm1.g3 on pm1.g2.e2 = pm1.g3.e2) on pm1.g1.e1 = pm1.g2.e1
> {code}
> There will be a join structure like:
> {code}
> JoinNode(1) [Dependent]
> AccessNode(2)
> JoinNode(3) [Dependent] [MERGE JOIN (ALREADY_SORTED/ALREADY_SORTED)]
> DependentAccessNode(4)
> DependentAccessNode(5)
> {code}
> Such that there is a dependent join as a left child of a merge join that is marked as having that child already sorted. When there is more than 1 query needed for DependentAccessNode(4), the DependentAccessNode will mistakenly mark the right child as needing to be sorted.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (TEIID-4179) Update the documentation of the ODBC with connection properties
by Ramesh Reddy (JIRA)
Ramesh Reddy created TEIID-4179:
-----------------------------------
Summary: Update the documentation of the ODBC with connection properties
Key: TEIID-4179
URL: https://issues.jboss.org/browse/TEIID-4179
Project: Teiid
Issue Type: Task
Components: Documentation
Reporter: Ramesh Reddy
Assignee: Ramesh Reddy
ConnSettings =SET resultSetCacheMode TO 'true'
That will set the connection property. Please this applies any connection property. If there are multiple, you delimit them by ; Similarly in Windows DSN wizard too.
In the vdb.xml, you can add a vdb level property like
<vdb name="...">
<property name="connection.resultSetCacheMode" value="true"/>
...
</vdb>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (TEIID-4178) OData and Rest wars use different conventions
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-4178:
-------------------------------------
Summary: OData and Rest wars use different conventions
Key: TEIID-4178
URL: https://issues.jboss.org/browse/TEIID-4178
Project: Teiid
Issue Type: Quality Risk
Components: OData, Server
Reporter: Steven Hawkins
Priority: Minor
Fix For: 9.x
OData uses vdb.version while Rest uses vdb_version. If we were to make them the same, there would still need to be a backwards compatibility mode.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (TEIID-4175) Certain nested dependent join structure will cause fewer results than expected
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-4175?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-4175:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1331421
Bugzilla Update: Perform
> Certain nested dependent join structure will cause fewer results than expected
> ------------------------------------------------------------------------------
>
> Key: TEIID-4175
> URL: https://issues.jboss.org/browse/TEIID-4175
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Blocker
> Fix For: 9.0, 8.12.5, 8.13.5
>
>
> With a query such as:
> {code}
> SELECT pm1.g1.e1, pm1.g2.e2 from /*+ makeind */ pm1.g1 inner join /*+ preserve */ (/*+ makeind */ pm1.g2 inner join pm1.g3 on pm1.g2.e2 = pm1.g3.e2) on pm1.g1.e1 = pm1.g2.e1
> {code}
> There will be a join structure like:
> {code}
> JoinNode(1) [Dependent]
> AccessNode(2)
> JoinNode(3) [Dependent] [MERGE JOIN (ALREADY_SORTED/ALREADY_SORTED)]
> DependentAccessNode(4)
> DependentAccessNode(5)
> {code}
> Such that there is a dependent join as a left child of a merge join that is marked as having that child already sorted. When there is more than 1 query needed for DependentAccessNode(4), the DependentAccessNode will mistakenly mark the right child as needing to be sorted.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (TEIID-4175) Certain nested dependent join structure will cause fewer results than expected
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4175?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-4175.
-----------------------------------
Resolution: Done
Updated the dependentaccessnode logic to change the sort option on the left as well. Also added assertions to prevent setting the sort order after it's too late - which may need fixed later.
> Certain nested dependent join structure will cause fewer results than expected
> ------------------------------------------------------------------------------
>
> Key: TEIID-4175
> URL: https://issues.jboss.org/browse/TEIID-4175
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Blocker
> Fix For: 9.0, 8.12.5, 8.13.5
>
>
> With a query such as:
> {code}
> SELECT pm1.g1.e1, pm1.g2.e2 from /*+ makeind */ pm1.g1 inner join /*+ preserve */ (/*+ makeind */ pm1.g2 inner join pm1.g3 on pm1.g2.e2 = pm1.g3.e2) on pm1.g1.e1 = pm1.g2.e1
> {code}
> There will be a join structure like:
> {code}
> JoinNode(1) [Dependent]
> AccessNode(2)
> JoinNode(3) [Dependent] [MERGE JOIN (ALREADY_SORTED/ALREADY_SORTED)]
> DependentAccessNode(4)
> DependentAccessNode(5)
> {code}
> Such that there is a dependent join as a left child of a merge join that is marked as having that child already sorted. When there is more than 1 query needed for DependentAccessNode(4), the DependentAccessNode will mistakenly mark the right child as needing to be sorted.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years