January 2019 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-5588) Please add support for earlyRequest feature which is for example used in the OpenUI5 library to enhance performance in single page apps

by Christoph John (Jira)

Christoph John created TEIID-5588: ------------------------------------- Summary: Please add support for earlyRequest feature which is for example used in the OpenUI5 library to enhance performance in single page apps Key: TEIID-5588 URL: https://issues.jboss.org/browse/TEIID-5588 Project: Teiid Issue Type: Enhancement Affects Versions: 11.2.1 Reporter: Christoph John Assignee: Steven Hawkins As discussed in https://issues.jboss.org/browse/TEIID-5545 OpenUI5 implements a earlyRequest feature to preload metadata information from an odata v4 service. It would be great if support for this could be added to Teiid/Widlfly. Thomas Chadzelek, who I assume is a lead developer for the odata v4 model kindly gave me the following information and offered his support if further questions arise: The "earlyRequests" parameter is pretty simple. It will send GET requests for /$metadata and all annotation XML files (see parameter "annotationURI"). It will also send a HEAD request to with header "X-CSRF-Token" : "Fetch" in order to fetch the security token. If Teiid/Olingo does not implement CSRF protection by requiring such a header, there should be no need to properly answer the HEAD request at all. Else it would be nice to return the right CSRF token value in the response's headers. Please see Cross-Site Request Forgery Protection and Gateway protection against Cross-Site Request Forgery attacks for some background infos. For further questions you can contact him directly by joining the discussion at: https://github.com/SAP/openui5/issues/2288 Thanks a lot. Let we know if I can support with testing. Best regards, Christoph -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5587) Oracle 11 drivers don't accept NVARCHAR type

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5587?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5587: ---------------------------------- > Oracle 11 drivers don't accept NVARCHAR type > -------------------------------------------- > > Key: TEIID-5587 > URL: https://issues.jboss.org/browse/TEIID-5587 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.0, 11.2.2 > > > Older oracle drivers, such as 11.2.0.1.0 do not accept the sql type NVARCHAR as an argument to set object, which results in an exception like: > {code} > Caused by: java.sql.SQLException: Invalid column type > at oracle.jdbc.driver.OraclePreparedStatement.setObjectCritical(OraclePreparedStatement.java:12187) > at oracle.jdbc.driver.OraclePreparedStatement.setObjectInternal(OraclePreparedStatement.java:11577) > at oracle.jdbc.driver.OraclePreparedStatement.setObject(OraclePreparedStatement.java:12286) > at oracle.jdbc.driver.OraclePreparedStatementWrapper.setObject(OraclePreparedStatementWrapper.java:548) > at org.teiid.translator.jdbc.JDBCExecutionFactory.bindValue(JDBCExecutionFactory.java:1145) > {code} > We can also safely narrow our usage of the n types with oracle as anything in the latin 1 supplement is still allowed in varchar values. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5587) Oracle 11 drivers don't accept NVARCHAR type

by Steven Hawkins (Jira)

Steven Hawkins created TEIID-5587: ------------------------------------- Summary: Oracle 11 drivers don't accept NVARCHAR type Key: TEIID-5587 URL: https://issues.jboss.org/browse/TEIID-5587 Project: Teiid Issue Type: Bug Components: JDBC Connector Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 12.0, 11.2.2 Older oracle drivers, such as 11.2.0.1.0 do not accept the sql type NVARCHAR as an argument to set object, which results in an exception like: {code} Caused by: java.sql.SQLException: Invalid column type at oracle.jdbc.driver.OraclePreparedStatement.setObjectCritical(OraclePreparedStatement.java:12187) at oracle.jdbc.driver.OraclePreparedStatement.setObjectInternal(OraclePreparedStatement.java:11577) at oracle.jdbc.driver.OraclePreparedStatement.setObject(OraclePreparedStatement.java:12286) at oracle.jdbc.driver.OraclePreparedStatementWrapper.setObject(OraclePreparedStatementWrapper.java:548) at org.teiid.translator.jdbc.JDBCExecutionFactory.bindValue(JDBCExecutionFactory.java:1145) {code} We can also safely narrow our usage of the n types with oracle as anything in the latin 1 supplement is still allowed in varchar values. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5586) NPE with buffer manager error log

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5586?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5586. ----------------------------------- Resolution: Done Updated the logic to check for a null list. > NPE with buffer manager error log > --------------------------------- > > Key: TEIID-5586 > URL: https://issues.jboss.org/browse/TEIID-5586 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.0, 11.2.2 > > > If the BatchManager is asked to describe a null object (already removed), then an NPE is thrown: > https://github.com/teiid/teiid/blob/cb7e4aacab01fbc17e891e5aa25bca1e960ad... -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5586) NPE with buffer manager error log

by Steven Hawkins (Jira)

Steven Hawkins created TEIID-5586: ------------------------------------- Summary: NPE with buffer manager error log Key: TEIID-5586 URL: https://issues.jboss.org/browse/TEIID-5586 Project: Teiid Issue Type: Bug Components: Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 12.0, 11.2.2 If the BatchManager is asked to describe a null object (already removed), then an NPE is thrown: https://github.com/teiid/teiid/blob/cb7e4aacab01fbc17e891e5aa25bca1e960ad... -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3747) Deploying a .vdb where a dynamic vdb has already been deployed, fails due to duplicates

by RH Bugzilla Integration (Jira)

[ https://issues.jboss.org/browse/TEIID-3747?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3747: ------------------------------------------------ Debi Rieden <drieden(a)redhat.com> changed the Status of [bug 1270336|https://bugzilla.redhat.com/show_bug.cgi?id=1270336] from ASSIGNED to CLOSED > Deploying a .vdb where a dynamic vdb has already been deployed, fails due to duplicates > --------------------------------------------------------------------------------------- > > Key: TEIID-3747 > URL: https://issues.jboss.org/browse/TEIID-3747 > Project: Teiid > Issue Type: Bug > Components: Server > Affects Versions: 8.7.1.6_2 > Reporter: Van Halbert > Assignee: Steven Hawkins > Priority: Major > Fix For: 8.12 > > > deployed a dynamic vdb using CLI: deploy teiidfiles/vdb/portfolio-vdb.xml > then in Designer, tried to deploy the same named VDB, but as a .vdb and the deployment fails with errors indicating duplicate service: > 11:26:31,301 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit."Portfolio.vdb".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."Portfolio.vdb".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "Portfolio.vdb" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55] > Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.teiid.ds-listener.Portfolio.1./accounts-ds is already registered > at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1] -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5585) Insert of a disk backed temporary lob into a temp table is un-readable

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5585?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5585. ----------------------------------- Resolution: Done Changed the auto cleanup tracking to mark lobs as temporary and remove the flag if inserted into a session or high scoped temporary table. If the lob is removed from the temporary table we are not yet auto cleaning it again. That is possible, but it would require reference tracking and/or creating copies of the original. > Insert of a disk backed temporary lob into a temp table is un-readable > ---------------------------------------------------------------------- > > Key: TEIID-5585 > URL: https://issues.jboss.org/browse/TEIID-5585 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.0 > > > This can be reproduced with a script like: > insert into #temp select 1 as x, cast(repeat('1', 4000) as clob) y; > insert into #temp select 2, concat((select y from #temp where x = 1), (select y from #temp where x = 1)); > insert into #temp select 3, concat((select y from #temp where x = 2), (select y from #temp where x = 2)); > insert into #temp select 4, concat((select y from #temp where x = 3), (select y from #temp where x = 3)); > insert into #temp select 5, concat((select y from #temp where x = 4), (select y from #temp where x = 4)); > -- will fail > insert into #temp select 6, concat((select y from #temp where x = 5), (select y from #temp where x = 5)) > The #5 clob is unreadable as the backing filestore is removed after insert. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5581) No @nextlink for virtualized procedure

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5581?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5581. ----------------------------------- Fix Version/s: 12.0 11.2.2 Resolution: Done Combined the complex response logic to handle both the procedure and cross join cases. Also consolidated the next link logic. Logged a follow on issue for xml formats. > No @nextlink for virtualized procedure > -------------------------------------- > > Key: TEIID-5581 > URL: https://issues.jboss.org/browse/TEIID-5581 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.12.16.6_4 > Reporter: Colin Mondesir > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.0, 11.2.2 > > Attachments: example.xmi, procExample_Odata_Results.xml, procExample_SELECT.sql > > > If we query a table "Field" via VDB, we get the following line in XML : > <a:link rel="next" href="http://<IP-address>:8080/odata4/UDVvdb.13/BusinessObjects/Field?$skiptoken=6lS4u9tYdm4j,256"/> > This allow end-user to loop on results easily. > But when we call virtualized procedure, we do not see that line. > It looks like : > <m:value xmlns:m="http://docs.oasis-open.org/odata/ns/metadata" xmlns:d="http://docs.oasis-open.org/odata/ns/data" xmlns:a="http://www.w3.org/2005/Atom" m:type="#Collection(UDVvdb.13.Wellmap.getOffsetWells_ResultSet)" m:context="$metadata#Collection(UDVvdb.13.Wellmap.getOffsetWells_ResultSet)"> > [List of <m:element>] > </m:value> > Odata batch is currently limited to 256 so without a next link it's not possible to get to the rest of the data. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5585) Insert of a disk backed temporary lob into a temp table is un-readable

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5585?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5585: --------------------------------------- The issue is actually with the auto-cleanup performed by the CommandContext tracking of created InputStreamFactories - they do not last from one statement to the next. So we need temporary tables to assume responsibility for any such lobs. > Insert of a disk backed temporary lob into a temp table is un-readable > ---------------------------------------------------------------------- > > Key: TEIID-5585 > URL: https://issues.jboss.org/browse/TEIID-5585 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.0 > > > This can be reproduced with a script like: > insert into #temp select 1 as x, cast(repeat('1', 4000) as clob) y; > insert into #temp select 2, concat((select y from #temp where x = 1), (select y from #temp where x = 1)); > insert into #temp select 3, concat((select y from #temp where x = 2), (select y from #temp where x = 2)); > insert into #temp select 4, concat((select y from #temp where x = 3), (select y from #temp where x = 3)); > insert into #temp select 5, concat((select y from #temp where x = 4), (select y from #temp where x = 4)); > -- will fail > insert into #temp select 6, concat((select y from #temp where x = 5), (select y from #temp where x = 5)) > The #5 clob is unreadable as the backing filestore is removed after insert. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5585) Insert of a disk backed temporary lob into a temp table is un-readable

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5585?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-5585: ---------------------------------- Description: This can be reproduced with a script like: insert into #temp select 1 as x, cast(repeat('1', 4000) as clob) y; insert into #temp select 2, concat((select y from #temp where x = 1), (select y from #temp where x = 1)); insert into #temp select 3, concat((select y from #temp where x = 2), (select y from #temp where x = 2)); insert into #temp select 4, concat((select y from #temp where x = 3), (select y from #temp where x = 3)); insert into #temp select 5, concat((select y from #temp where x = 4), (select y from #temp where x = 4)); -- will fail insert into #temp select 6, concat((select y from #temp where x = 5), (select y from #temp where x = 5)) The #5 clob is unreadable as the backing filestore is removed after insert. was: This can be reproduced with a script like: insert into #temp select 1 as x, cast(repeat('1', 4000) as clob) y; insert into #temp select 2, concat((select y from #temp where x = 1), (select y from #temp where x = 1)); insert into #temp select 3, concat((select y from #temp where x = 2), (select y from #temp where x = 2)); insert into #temp select 4, concat((select y from #temp where x = 3), (select y from #temp where x = 3)); -- will fail insert into #temp select 5, concat((select y from #temp where x = 4), (select y from #temp where x = 4)); The #4 clob is unreadable as the backing filestore is removed after insert. > Insert of a disk backed temporary lob into a temp table is un-readable > ---------------------------------------------------------------------- > > Key: TEIID-5585 > URL: https://issues.jboss.org/browse/TEIID-5585 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 12.0 > > > This can be reproduced with a script like: > insert into #temp select 1 as x, cast(repeat('1', 4000) as clob) y; > insert into #temp select 2, concat((select y from #temp where x = 1), (select y from #temp where x = 1)); > insert into #temp select 3, concat((select y from #temp where x = 2), (select y from #temp where x = 2)); > insert into #temp select 4, concat((select y from #temp where x = 3), (select y from #temp where x = 3)); > insert into #temp select 5, concat((select y from #temp where x = 4), (select y from #temp where x = 4)); > -- will fail > insert into #temp select 6, concat((select y from #temp where x = 5), (select y from #temp where x = 5)) > The #5 clob is unreadable as the backing filestore is removed after insert. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues January 2019