[JBoss JIRA] (TEIID-4919) Sybase 15.7: running into'CREATE TABLE' command is not allowed within a multi-statement transaction in the 'tempdb' database.
by Ivan Chan (JIRA)
[ https://issues.jboss.org/browse/TEIID-4919?page=com.atlassian.jira.plugin... ]
Ivan Chan commented on TEIID-4919:
----------------------------------
I was not able to verify this issue yet. I need permission to change sybase settings, but please feel free to close this issue for now. I will update it in a week or so.
> Sybase 15.7: running into'CREATE TABLE' command is not allowed within a multi-statement transaction in the 'tempdb' database.
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-4919
> URL: https://issues.jboss.org/browse/TEIID-4919
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 9.1.1
> Reporter: Ivan Chan
> Assignee: Steven Hawkins
>
> When I try to build VDB with sybase ASE 15.7 odb schema, I run into the following error:
> Caused by: java.sql.SQLException: The 'CREATE TABLE' command is not allowed within a multi-statement transaction in the 'tempdb' database.
> at com.sybase.jdbc4.jdbc.SybConnection.getAllExceptions(Unknown Source)
> at com.sybase.jdbc4.jdbc.SybStatement.handleSQLE(Unknown Source)
> at com.sybase.jdbc4.jdbc.SybStatement.nextResult(Unknown Source)
> at com.sybase.jdbc4.jdbc.SybStatement.nextResult(Unknown Source)
> at com.sybase.jdbc4.jdbc.SybStatement.queryLoop(Unknown Source)
> at com.sybase.jdbc4.jdbc.SybStatement.executeQuery(Unknown Source)
> at com.sybase.jdbc4.jdbc.SybCallableStatement.executeQuery(Unknown Source)
> at com.sybase.jdbc4.jdbc.SybDatabaseMetaData.if(Unknown Source)
> at com.sybase.jdbc4.jdbc.SybDatabaseMetaData.getColumns(Unknown Source)
> at org.apache.commons.dbcp.DelegatingDatabaseMetaData.getColumns(DelegatingDatabaseMetaData.java:218)
> at org.teiid.translator.jdbc.JDBCMetdataProcessor.getColumns(JDBCMetdataProcessor.java:382)
> at org.teiid.translator.jdbc.JDBCMetdataProcessor.getTables(JDBCMetdataProcessor.java:334)
> at org.teiid.translator.jdbc.JDBCMetdataProcessor.getConnectorMetadata(JDBCMetdataProcessor.java:173)
> at org.teiid.translator.jdbc.JDBCExecutionFactory.getMetadata(JDBCExecutionFactory.java:306)
> ... 182 more
> I am using this driver: jconn4.jar [ com.sybase.jdbc4.jdbc.SybDriver ]
> And org.teiid.translator.jdbc.sybase.SybaseExecutionFactor
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 12 months
[JBoss JIRA] (TEIID-4926) Couchbase - unable to retrieve data if using 'convert' in view definition
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-4926?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-4926:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1455927
Bugzilla Update: Perform
> Couchbase - unable to retrieve data if using 'convert' in view definition
> -------------------------------------------------------------------------
>
> Key: TEIID-4926
> URL: https://issues.jboss.org/browse/TEIID-4926
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 9.3, 8.12.x-6.4
> Reporter: Juraj Duráni
> Assignee: Kylin Soong
> Priority: Blocker
> Fix For: 9.3, 8.12.x-6.4
>
>
> I have a simple document structure in Couchbase (no nested documents, all values are strings, integers, and booleans).
> I have a source model with proper types (strings, integers, booleans) and view model defined with my target types (float, double, date,...) all with appropriate conversion.
> There are basically two issues:
> - When I try to retrieve all data from the view, Teiid ends with exception \[1\]. This is wired.
> - When I try to use explicit convert on some columns from source table (not view) it ends with similar exception \[2\].
> Additional information:
> I represent 'Null' values by excluding key from the document (nevertheless, same error occurs even if I add explicit "key":null to the definition of the document).
> \[1\]
> TEIID10076 Invalid conversion from type class java.lang.Integer with value '-24' to type class java.sql.Date
> \[2\] - case for data value
> TEIID10076 Invalid conversion from type class java.lang.Object with value '\{\}' to type class java.sql.Date
> \[3\] - Queries
> {code:sql}
> OK - select * from couchbase.smalla
> FAIL - select * from bqt1.smalla
> FAIL - select convert(datevalue, date) from couchbase.smalla
> {code}
> \[4\] VDB definition
> {code:sql}
> -- source model
> SET NAMESPACE 'http://www.teiid.org/translator/couchbase/2017' AS teiid_couchbase;
> CREATE FOREIGN TABLE SmallA (
> documentID string,
> FloatNum integer OPTIONS (NAMEINSOURCE '`smalla`.`FloatNum`'),
> IntKey integer PRIMARY KEY OPTIONS (NAMEINSOURCE '`smalla`.`IntKey`'),
> BigIntegerValue integer OPTIONS (NAMEINSOURCE '`smalla`.`BigIntegerValue`'),
> StringKey string OPTIONS (NAMEINSOURCE '`smalla`.`StringKey`'),
> CharValue string OPTIONS (NAMEINSOURCE '`smalla`.`CharValue`'),
> LongNum integer OPTIONS (NAMEINSOURCE '`smalla`.`LongNum`'),
> type string OPTIONS (NAMEINSOURCE '`smalla`.`type`'),
> DoubleNum integer OPTIONS (NAMEINSOURCE '`smalla`.`DoubleNum`'),
> ObjectValue string OPTIONS (NAMEINSOURCE '`smalla`.`ObjectValue`'),
> ShortValue integer OPTIONS (NAMEINSOURCE '`smalla`.`ShortValue`'),
> BigDecimalValue integer OPTIONS (NAMEINSOURCE '`smalla`.`BigDecimalValue`'),
> DateValue string OPTIONS (NAMEINSOURCE '`smalla`.`DateValue`'),
> BooleanValue boolean OPTIONS (NAMEINSOURCE '`smalla`.`BooleanValue`'),
> TimestampValue string OPTIONS (NAMEINSOURCE '`smalla`.`TimestampValue`'),
> ByteNum integer OPTIONS (NAMEINSOURCE '`smalla`.`ByteNum`'),
> StringNum string OPTIONS (NAMEINSOURCE '`smalla`.`StringNum`'),
> TimeValue string OPTIONS (NAMEINSOURCE '`smalla`.`TimeValue`'),
> IntNum integer OPTIONS (NAMEINSOURCE '`smalla`.`IntNum`')
> ) OPTIONS (NAMEINSOURCE '`smalla`', UPDATABLE FALSE, "teiid_couchbase:ISARRAYTABLE" 'false', "teiid_couchbase:NAMEDTYPEPAIR" '`type`:''SmallA''');
> -- view model
> CREATE VIEW SmallA (
> IntKey integer PRIMARY KEY,
> StringKey string,
> IntNum integer,
> StringNum string,
> FloatNum float,
> LongNum long,
> DoubleNum double,
> ByteNum byte,
> DateValue date,
> TimeValue time,
> TimestampValue timestamp,
> BooleanValue boolean,
> CharValue char(1),
> ShortValue short,
> BigIntegerValue biginteger,
> BigDecimalValue bigdecimal,
> ObjectValue object)
> AS
> SELECT
> IntKey, StringKey, IntNum, StringNum, convert(FloatNum, float) AS FloatNum, convert(LongNum, long) AS LongNum,
> convert(DoubleNum, double) AS DoubleNum, convert(ByteNum, byte) AS ByteNum, convert(DateValue, date) AS DateValue,
> convert(TimeValue, time) AS TimeValue, convert(TimestampValue, timestamp) AS TimstampValue, BooleanValue,
> convert(CharValue, char) AS CharValue, convert(ShortValue, short) AS ShortValue, convert(BigIntegerValue, biginteger) AS BigIntegerValue,
> convert(BigDecimalValue, bigdecimal) AS BigDecimalValue, convert(ObjectValue, object) AS ObjectValue
> FROM
> Couchbase.SmallA;
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 12 months
[JBoss JIRA] (TEIID-4937) OAuth2 security with OData seems to outdated with current Keycloak 3.1.0
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4937?page=com.atlassian.jira.plugin... ]
Ramesh Reddy resolved TEIID-4937.
---------------------------------
Resolution: Done
Updated the document. Ideally, I want to provide multiple WAR files, but that would require bigger changes which we will handle in 10.x
> OAuth2 security with OData seems to outdated with current Keycloak 3.1.0
> ------------------------------------------------------------------------
>
> Key: TEIID-4937
> URL: https://issues.jboss.org/browse/TEIID-4937
> Project: Teiid
> Issue Type: Bug
> Components: Documentation, OData
> Affects Versions: 9.0
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Fix For: 9.3
>
>
> Running through the OData WAR to enable the OAuth2 security seems to have improved a lot and can be simplified. The document does need changes to reflect it.
> Also, we could provide an additional WAR file, where changes to WAR file such as overlay or rebuilding of it can be eliminated.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 12 months
[JBoss JIRA] (TEIID-4861) ASSERTION FAILED: expected reference to be not null
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-4861?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-4861:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1455837, https://bugzilla.redhat.com/show_bug.cgi?id=1455921 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1455837)
> ASSERTION FAILED: expected reference to be not null
> ---------------------------------------------------
>
> Key: TEIID-4861
> URL: https://issues.jboss.org/browse/TEIID-4861
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 9.0.2, 9.2.1, 9.2.2
> Reporter: Harold Campbell
> Assignee: Steven Hawkins
> Fix For: 9.3, 9.2.3, 8.12.11.6_3
>
> Attachments: DEBUG_LOG, DEBUG_LOG_WORKS
>
>
> I have a vdb containing a multi-source schema (channel) and a single source schema (ops). The following query which uses an aggregate function and groups by both a mulit-source column and a single source column causes the error "TEIID30019 Unexpected exception for request l1HvA1r84nyA.0: java.lang.AssertionError: ASSERTION FAILED: expected reference to be not null" and a stack trace which looks quite similar to that in TEIID-4325:
> {code}
> select s.channel, m.user_name, count(*)
> from channel.dbo.service_request s
> join ops.dbo.manager m
> on s.staff_id = m.manager_id
> group by s.channel, m.user_name;
> {code}
> Apr 15 20:09:52 localhost docker[27044]: 2017-04-16 01:09:52,237 ERROR [org.teiid.PROCESSOR] (Worker2_QueryProcessorQueue7) l1HvA1r84nyA TEIID30019 Unexpected exception for request l1HvA1r84nyA.0: java.lang.AssertionError: ASSERTION FAILED: expected reference to be not null
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.core.util.Assertion.failed(Assertion.java:73)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.core.util.Assertion.isNotNull(Assertion.java:100)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.core.util.Assertion.isNotNull(Assertion.java:92)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.relational.RelationalNode.getProjectionIndexes(RelationalNode.java:367)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.relational.JoinNode.initialize(JoinNode.java:133)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:96)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:102)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:102)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.relational.RelationalPlan.connectExternal(RelationalPlan.java:102)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.relational.RelationalPlan.initialize(RelationalPlan.java:91)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.QueryProcessor.init(QueryProcessor.java:226)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:138)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:477)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:349)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:275)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:282)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
> Apr 15 20:09:52 localhost docker[27044]: at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
> Apr 15 20:09:52 localhost docker[27044]: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> Apr 15 20:09:52 localhost docker[27044]: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> Apr 15 20:09:52 localhost docker[27044]: at java.lang.Thread.run(Thread.java:745)
> Interestingly, if I narrow the query down to specific channels the error goes away:
> {code}
> select s.channel, m.user_name, count(*)
> from channel.dbo.service_request s
> join ops.dbo.manager m
> on s.staff_id = m.manager_id
> where channel in ('oak', 'cypress')
> group by s.channel, m.user_name;
> {code}
> I will attach both query plans.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 12 months
[JBoss JIRA] (TEIID-4937) OAuth2 security with OData seems to outdated with current Keycloak 3.1.0
by Ramesh Reddy (JIRA)
Ramesh Reddy created TEIID-4937:
-----------------------------------
Summary: OAuth2 security with OData seems to outdated with current Keycloak 3.1.0
Key: TEIID-4937
URL: https://issues.jboss.org/browse/TEIID-4937
Project: Teiid
Issue Type: Bug
Components: Documentation, OData
Affects Versions: 9.0
Reporter: Ramesh Reddy
Assignee: Ramesh Reddy
Fix For: 9.3
Running through the OData WAR to enable the OAuth2 security seems to have improved a lot and can be simplified. The document does need changes to reflect it.
Also, we could provide an additional WAR file, where changes to WAR file such as overlay or rebuilding of it can be eliminated.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 12 months
[JBoss JIRA] (TEIID-4934) Allow importing VDBs with conflicting model
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4934?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-4934:
-------------------------------------
I guess if we treat if the same named VDB is being loaded again, or recursively if omit it, or if same named model is being loaded then avoid loading based on flag might work. Teiid may need to load import vdbs as the last action.
> Allow importing VDBs with conflicting model
> -------------------------------------------
>
> Key: TEIID-4934
> URL: https://issues.jboss.org/browse/TEIID-4934
> Project: Teiid
> Issue Type: Enhancement
> Affects Versions: 9.2.3
> Environment: * Wildfly 10
> * Teiid Server 9.2.3
> Reporter: Pedro Inácio
> Assignee: Steven Hawkins
>
> It should be possible to import a model via "_import-vdb_" that conflicts with other models also imported via "_import-vdb_" if the conflicting model has the same version.
> This will allow greater model reuse, and not to have duplicated model definitions in multiple vdbs.
> Example:
> VDB 1:
> <code>
> <vdb name="OneVDB" version="1">
> <description>One VDB</description>
> <import-vdb name=ConflictingVDB" version="1"/>
> <import-vdb name="OtherVDB" version="1"/>
> </code>
> VDB 2:
> <code>
> <vdb name="TwoVDB" version="1">
> <description>TwoVDB</description>
> <import-vdb name=ConflictingVDB" version="1"/>
> <import-vdb name="YetOtherVDB" version="1"/>
> </code>
> VDB 3:
> <code>
> <vdb name="ThirdVDB" version="1">
> <description>Third VDB</description>
> <import-vdb name=OneVDB" version="1"/>
> <import-vdb name="TwoVDB" version="1"/>
> </code>
> Currently we cannot use the ThirdVDB as is, since there is a conflicting VDB (ConflictingVDB) defined in VDBS One and Two.
> Since both are using the same version, it should be possible to ignore the conflict (via a property for example).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 12 months
[JBoss JIRA] (TEIID-4919) Sybase 15.7: running into'CREATE TABLE' command is not allowed within a multi-statement transaction in the 'tempdb' database.
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4919?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4919:
---------------------------------------
Can you confirm the workaround?
> Sybase 15.7: running into'CREATE TABLE' command is not allowed within a multi-statement transaction in the 'tempdb' database.
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-4919
> URL: https://issues.jboss.org/browse/TEIID-4919
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 9.1.1
> Reporter: Ivan Chan
> Assignee: Steven Hawkins
>
> When I try to build VDB with sybase ASE 15.7 odb schema, I run into the following error:
> Caused by: java.sql.SQLException: The 'CREATE TABLE' command is not allowed within a multi-statement transaction in the 'tempdb' database.
> at com.sybase.jdbc4.jdbc.SybConnection.getAllExceptions(Unknown Source)
> at com.sybase.jdbc4.jdbc.SybStatement.handleSQLE(Unknown Source)
> at com.sybase.jdbc4.jdbc.SybStatement.nextResult(Unknown Source)
> at com.sybase.jdbc4.jdbc.SybStatement.nextResult(Unknown Source)
> at com.sybase.jdbc4.jdbc.SybStatement.queryLoop(Unknown Source)
> at com.sybase.jdbc4.jdbc.SybStatement.executeQuery(Unknown Source)
> at com.sybase.jdbc4.jdbc.SybCallableStatement.executeQuery(Unknown Source)
> at com.sybase.jdbc4.jdbc.SybDatabaseMetaData.if(Unknown Source)
> at com.sybase.jdbc4.jdbc.SybDatabaseMetaData.getColumns(Unknown Source)
> at org.apache.commons.dbcp.DelegatingDatabaseMetaData.getColumns(DelegatingDatabaseMetaData.java:218)
> at org.teiid.translator.jdbc.JDBCMetdataProcessor.getColumns(JDBCMetdataProcessor.java:382)
> at org.teiid.translator.jdbc.JDBCMetdataProcessor.getTables(JDBCMetdataProcessor.java:334)
> at org.teiid.translator.jdbc.JDBCMetdataProcessor.getConnectorMetadata(JDBCMetdataProcessor.java:173)
> at org.teiid.translator.jdbc.JDBCExecutionFactory.getMetadata(JDBCExecutionFactory.java:306)
> ... 182 more
> I am using this driver: jconn4.jar [ com.sybase.jdbc4.jdbc.SybDriver ]
> And org.teiid.translator.jdbc.sybase.SybaseExecutionFactor
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 12 months
[JBoss JIRA] (TEIID-4934) Allow importing VDBs with conflicting model
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4934?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4934:
---------------------------------------
[~rareddy] He's asking not looking for a renaming, just that in VDB 3 ConflictingVDB is imported and not seen as a conflict.
However as Ramesh is indicating, the internals are not quite setup for this. The only way I can think of to do this easily is if VDB 1/2 were just declared using VDB imports - no additional models, then it would be easy to resolve them together in the parent.
> Allow importing VDBs with conflicting model
> -------------------------------------------
>
> Key: TEIID-4934
> URL: https://issues.jboss.org/browse/TEIID-4934
> Project: Teiid
> Issue Type: Enhancement
> Affects Versions: 9.2.3
> Environment: * Wildfly 10
> * Teiid Server 9.2.3
> Reporter: Pedro Inácio
> Assignee: Steven Hawkins
>
> It should be possible to import a model via "_import-vdb_" that conflicts with other models also imported via "_import-vdb_" if the conflicting model has the same version.
> This will allow greater model reuse, and not to have duplicated model definitions in multiple vdbs.
> Example:
> VDB 1:
> <code>
> <vdb name="OneVDB" version="1">
> <description>One VDB</description>
> <import-vdb name=ConflictingVDB" version="1"/>
> <import-vdb name="OtherVDB" version="1"/>
> </code>
> VDB 2:
> <code>
> <vdb name="TwoVDB" version="1">
> <description>TwoVDB</description>
> <import-vdb name=ConflictingVDB" version="1"/>
> <import-vdb name="YetOtherVDB" version="1"/>
> </code>
> VDB 3:
> <code>
> <vdb name="ThirdVDB" version="1">
> <description>Third VDB</description>
> <import-vdb name=OneVDB" version="1"/>
> <import-vdb name="TwoVDB" version="1"/>
> </code>
> Currently we cannot use the ThirdVDB as is, since there is a conflicting VDB (ConflictingVDB) defined in VDBS One and Two.
> Since both are using the same version, it should be possible to ignore the conflict (via a property for example).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 12 months