[JBoss JIRA] (TEIID-2457) Assertion error with INTERSECT
by Graeme Gillies (JIRA)
[ https://issues.jboss.org/browse/TEIID-2457?page=com.atlassian.jira.plugin... ]
Graeme Gillies commented on TEIID-2457:
---------------------------------------
Hi,
After further investigation we discovered that *all* queries failed not just ones against the SYS schema.
Even more playing around revealed that the error occurs when you have a postgresql real database as one of the datasources in your dynamic vdb. As soon as you remove all postgresql sources (and just use mysql) it seems to work
> Assertion error with INTERSECT
> ------------------------------
>
> Key: TEIID-2457
> URL: https://issues.jboss.org/browse/TEIID-2457
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.3, 7.7.6
> Reporter: Van Halbert
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 8.4
>
>
> A sample query which produced the error is: SELECT IntKey FROM BQT1.SmallA INTERSECT SELECT IntNum FROM BQT1.SmallB ORDER BY INTKEY
> How to reproduce: Run the query using a client such as Squirrel multiple times. The results varies from returning an Assertion to returning actual results. In my test I ran the query five times and it returned actual results twice and the Assertion 3 times. The Assertion can be seen below.
> 2013-04-03 16:00:42,190 ERROR [org.teiid.PROCESSOR] (Worker4_QueryProcessorQueue146) Unexpected exception for request JyDs6MZ6d9zG.24
> java.lang.AssertionError: ASSERTION FAILED: expected reference to be not null
> at org.teiid.core.util.Assertion.failed(Assertion.java:73)
> at org.teiid.core.util.Assertion.isNotNull(Assertion.java:100)
> at org.teiid.core.util.Assertion.isNotNull(Assertion.java:92)
> at org.teiid.common.buffer.TupleBuffer.getBatch(TupleBuffer.java:217)
> at org.teiid.common.buffer.TupleBuffer$1.getBatch(TupleBuffer.java:331)
> at org.teiid.common.buffer.AbstractTupleSource.getCurrentTuple(AbstractTupleSource.java:61)
> at org.teiid.common.buffer.AbstractTupleSource.hasNext(AbstractTupleSource.java:91)
> at org.teiid.query.processor.relational.MergeJoinStrategy.process(MergeJoinStrategy.java:163)
> at org.teiid.query.processor.relational.JoinNode.nextBatchDirect(JoinNode.java:212)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:280)
> at org.teiid.query.processor.BatchIterator.finalRow(BatchIterator.java:70)
> at org.teiid.common.buffer.AbstractTupleSource.getCurrentTuple(AbstractTupleSource.java:69)
> at org.teiid.query.processor.BatchIterator.getCurrentTuple(BatchIterator.java:85)
> at org.teiid.common.buffer.AbstractTupleSource.nextTuple(AbstractTupleSource.java:48)
> at org.teiid.query.processor.relational.SortUtility.initialSort(SortUtility.java:248)
> at org.teiid.query.processor.relational.SortUtility.sort(SortUtility.java:185)
> at org.teiid.query.processor.relational.SortNode.sortPhase(SortNode.java:99)
> at org.teiid.query.processor.relational.SortNode.nextBatchDirect(SortNode.java:88)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:280)
> at org.teiid.query.processor.relational.LimitNode.nextBatchDirect(LimitNode.java:100)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:280)
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:176)
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:139)
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:105)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:147)
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:375)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:288)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:49)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:216)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:244)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:122)
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:292)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (TEIID-2479) Selecting from SYS model throws exception
by Graeme Gillies (JIRA)
Graeme Gillies created TEIID-2479:
-------------------------------------
Summary: Selecting from SYS model throws exception
Key: TEIID-2479
URL: https://issues.jboss.org/browse/TEIID-2479
Project: Teiid
Issue Type: Bug
Affects Versions: 8.3
Environment: Teiid 8.3 running in JBoss EAP 6.0 RPM install
java version "1.7.0_09-icedtea"
OpenJDK Runtime Environment (rhel-2.3.8.0.el6_4-x86_64)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
Reporter: Graeme Gillies
Assignee: Steven Hawkins
We have a dynamic vdb deployed into our Teiid 8.3 environment, but whenever we connect to the vdb via the pgsql emulation socket using the standard postgresql tools, and attempt to select any value from any tables in the SYS scheama, we are given an error
{noformat}
TestVDB=> select * from sys.keys;
ERROR: Group specified is ambiguous, resubmit the query by fully qualifying the group name: pg_attribute
DETAIL: org.teiid.jdbc.TeiidSQLException: Group specified is ambiguous, resubmit the query by fully qualifying the group name: pg_attribute
TestVDB=> select * from sys.columns;
ERROR: Group specified is ambiguous, resubmit the query by fully qualifying the group name: pg_attribute
DETAIL: org.teiid.jdbc.TeiidSQLException: Group specified is ambiguous, resubmit the query by fully qualifying the group name: pg_attribute
TestVDB=> select * from sys.tables;
ERROR: Group specified is ambiguous, resubmit the query by fully qualifying the group name: pg_attribute
DETAIL: org.teiid.jdbc.TeiidSQLException: Group specified is ambiguous, resubmit the query by fully qualifying the group name: pg_attribute
TestVDB=>
{noformat}
It looks like the teiid parser is getting confused somehow with multiple pg_attribute fields on those tables or something.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (TEIID-2478) incomplete with pushdown
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-2478:
-------------------------------------
Summary: incomplete with pushdown
Key: TEIID-2478
URL: https://issues.jboss.org/browse/TEIID-2478
Project: Teiid
Issue Type: Bug
Components: Query Engine
Affects Versions: 7.7
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 8.4
If all the with clauses are not fully pushed, but is still pushable, the resulting query plan will contain incomplete references to the clauses.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (TEIID-2477) Standardize and correct jdbc database version comparisons
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2477?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2477:
---------------------------------------
For backporting a more narrow fix could be considered and/or to leave the string constants in place (in case they are in use by custom code).
> Standardize and correct jdbc database version comparisons
> ---------------------------------------------------------
>
> Key: TEIID-2477
> URL: https://issues.jboss.org/browse/TEIID-2477
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 7.0
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.4
>
>
> The simple string comparison of versions is not correct across version numbers of differing digits (10 is not higher than 9). Generally the field needs standardized as well since for example we use the year designations for SQL Server but the driver reported version numbers will be the actual software versions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (TEIID-2477) Standardize and correct jdbc database version comparisons
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2477?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2477.
-----------------------------------
Resolution: Done
Introduced a Version class to parse and provide a safe comparison for version numbers. This mostly replaced the usage of getDatabaseVersion with getVersion and changed most of the static string constants to Version constants.
Updated the release notes and the docs appropriately.
> Standardize and correct jdbc database version comparisons
> ---------------------------------------------------------
>
> Key: TEIID-2477
> URL: https://issues.jboss.org/browse/TEIID-2477
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 7.0
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.4
>
>
> The simple string comparison of versions is not correct across version numbers of differing digits (10 is not higher than 9). Generally the field needs standardized as well since for example we use the year designations for SQL Server but the driver reported version numbers will be the actual software versions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (TEIID-2344) Determine database version automatically
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2344?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2344.
-----------------------------------
Resolution: Done
Took the approach of adding new ExecutionFactory methods
isSourceRequiredForCapabilities
initCapabilities
If isSourceRequiredForCapabilities returns true (which will currently only the the case for the specific JDBC translator subtypes that use the database version property), then we'll attempt to pass a connection to the initCapabilities method.
If this fails, then we still allow planning to proceed and only fail if the final plan form still accesses a source that was planned without capabilities. This prevents invalid plans from ever being created, but is slightly different than the expectation of partial results mode - so that may still need users to set a version manually.
Compatibility and configuration issues are in the release notes.
TEIID-2477 is required however as we're currently just setting the raw product version, which needs better handling.
> Determine database version automatically
> ----------------------------------------
>
> Key: TEIID-2344
> URL: https://issues.jboss.org/browse/TEIID-2344
> Project: Teiid
> Issue Type: Enhancement
> Components: JDBC Connector
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.4
>
>
> It would be helpful if we could determine the database version automatically from the database metadata rather than relying on the user setting. Of course if the property setting is present we shouldn't override it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (TEIID-2477) Standardize and correct jdbc database version comparisons
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-2477:
-------------------------------------
Summary: Standardize and correct jdbc database version comparisons
Key: TEIID-2477
URL: https://issues.jboss.org/browse/TEIID-2477
Project: Teiid
Issue Type: Bug
Components: JDBC Connector
Affects Versions: 7.0
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 8.4
The simple string comparison of versions is not correct across version numbers of differing digits (10 is not higher than 9). Generally the field needs standardized as well since for example we use the year designations for SQL Server but the driver reported version numbers will be the actual software versions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month
[JBoss JIRA] (TEIID-2390) Improve xml/json production
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2390?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2390:
---------------------------------------
There isn't quite a straight-forward way to do this with our current logic. The bottom up evaluation would need some kind of top down handling - but nothing like that exists in the evaluator or the static implementation classes.
> Improve xml/json production
> ---------------------------
>
> Key: TEIID-2390
> URL: https://issues.jboss.org/browse/TEIID-2390
> Project: Teiid
> Issue Type: Enhancement
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.4
>
>
> The current xml/json logic can produce a lot of intermediate results that are recopied and can result in a slower performance for larger documents.
> The logic could allow for nested evaluations to delay creating their full string forms or simply allow the return values to remain appendable rather than requiring full copies.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 1 month