[JBoss JIRA] (TEIID-2711) Better support for Oracle SQLXML values
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2711?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2711:
---------------------------------------
Also another workaround (similar to the patch) is to alter the source xml column type to instead by clob and use a native-query on the table to convert that column to a clob:
select col1, col2, to_clob(xml_col) ... from tbl
Based upon this workaround and the documented (but not locally verified) approach from the first comment, I'm inclined to not commit this just yet.
> Better support for Oracle SQLXML values
> ---------------------------------------
>
> Key: TEIID-2711
> URL: https://issues.jboss.org/browse/TEIID-2711
> Project: Teiid
> Issue Type: Quality Risk
> Components: JDBC Connector
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Attachments: oracle.patch
>
>
> When using a typical driver configuration to read oracle xml values, the driver will return an OPAQUE instance rather than a SQLXML value.
--
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, 2 months
[JBoss JIRA] (TEIID-2711) Better support for Oracle SQLXML values
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-2711:
-------------------------------------
Summary: Better support for Oracle SQLXML values
Key: TEIID-2711
URL: https://issues.jboss.org/browse/TEIID-2711
Project: Teiid
Issue Type: Quality Risk
Components: JDBC Connector
Reporter: Steven Hawkins
Assignee: Steven Hawkins
When using a typical driver configuration to read oracle xml values, the driver will return an OPAQUE instance rather than a SQLXML value.
--
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, 2 months
[JBoss JIRA] (TEIID-2363) proactive buffering not occurring for the inner side of an outer join on "MERGE JOIN (SORT/ALREADY_SORTED)"
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2363?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2363.
-----------------------------------
Resolution: Done
Re-resolving by pulling out of 7.7.9. Addressed in 8.4.1 and 8.6 with TEIID-2707.
> proactive buffering not occurring for the inner side of an outer join on "MERGE JOIN (SORT/ALREADY_SORTED)"
> -----------------------------------------------------------------------------------------------------------
>
> Key: TEIID-2363
> URL: https://issues.jboss.org/browse/TEIID-2363
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Affects Versions: 7.7.2
> Reporter: Johnathon Lee
> Assignee: Steven Hawkins
> Fix For: 7.7.7, 8.4
>
>
> The issue here is this is an outer join and the inner side (the already sorted side) will be buffered regardless. Current logic does not catch blocked exceptions from one side and pro-actively buffer the other - rather we are serially performing the sort and then continue with the loading of the inner side
> For inner joins there is a clear trade-off between execution speed and buffering so this behavior may have to be hint or config driven for non-dependent non-outer joins.
--
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, 2 months
[JBoss JIRA] (TEIID-2710) Rest procedures should support optional parameters
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-2710:
-------------------------------------
Summary: Rest procedures should support optional parameters
Key: TEIID-2710
URL: https://issues.jboss.org/browse/TEIID-2710
Project: Teiid
Issue Type: Enhancement
Components: Server
Reporter: Steven Hawkins
Assignee: Steven Hawkins
We need to test our rest logic to ensure it supports optional parameters in the uri pattern:
{code}@Path("/mypath{param1 : (/param2)?}"){code}
And then update the procedure call to use named parameters so that defaultable missing parameters will use defaults (similar to the TeiidProducer/LocalClient logic used for OData).
--
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, 2 months
[JBoss JIRA] (TEIID-2690) Tuples lost in a with clause item.
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2690?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-2690:
----------------------------------
Fix Version/s: 7.7.8
> Tuples lost in a with clause item.
> ----------------------------------
>
> Key: TEIID-2690
> URL: https://issues.jboss.org/browse/TEIID-2690
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.1, 7.7.7
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Blocker
> Fix For: 8.4.1, 8.6, 7.7.8
>
>
> Related to TEIID-2442 - the BatchIterator created for the creation of the temp table backing a with clause item cannot be created after blocking without loosing tuples.
> On 8.3.x+ a single block is not sufficient to induce this behavior if there are any tuples that have been retrieved since the last block as the access node logic will return the partial batch. Thus may occur as a somewhat rare timing issue in 8.3.x+. However in 7.7.7/7.7.8 a single block cause the recreation of the BatchIterator making the affect almost certain once the row count exceeds the computed working batch size (nominally 256 rows, but allowed to vary based upon the row width).
--
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, 2 months