[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)
6 years
[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)
6 years
[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)
6 years
[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)
6 years
[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)
6 years
[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)
6 years
[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)
6 years
[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)
6 years