[JBoss JIRA] (TEIID-3474) Inconsistent results of RIGHT function for different datasources
by Juraj Duráni (JIRA)
[ https://issues.jboss.org/browse/TEIID-3474?page=com.atlassian.jira.plugin... ]
Juraj Duráni commented on TEIID-3474:
-------------------------------------
There are actually 3 columns in the result. I have used "|" as delimiter of columns in the original comment.
"-2.40000000000000E 001" is the string representation of numeric in the Teradata.
> Inconsistent results of RIGHT function for different datasources
> ----------------------------------------------------------------
>
> Key: TEIID-3474
> URL: https://issues.jboss.org/browse/TEIID-3474
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 7.7
> Environment: OS: Fedora 20
> arch: x86_64
> java: oracle 1.8
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
> Fix For: 8.7.1.6_2, 8.11
>
>
> The RIGHT function returns different results for different datasources. Some of those results are inconsistent with definition of the RIGHT(x,y) function.
> =======
> +*Query: SELECT intkey, RIGHT(intkey, 1) FROM table ORDER BY intkey*+
> *Teradata, SQLServer, Sybase, Ingres, MySQL, Oracle (this result is OK):*
> 0 0
> 1 1
> 2 2
> ...
> 10 0
> 11 1
> ...
> 100 0
> 101 1
> *Postgres:*
> 0 0
> 1 1
> 2 2
> ...
> 10 10
> 11 11
> ...
> 100 100
> 101 101
> *DB2:*
> 0 " "
> 1 " "
> 2 " "
> ...
> 10 " "
> 11 " "
> ...
> 100 " "
> 101 " "
> =====
> +*Query:SELECT intkey, RIGHT(intkey, 2) FROM table ORDER BY intkey*+
> *SQLServer, Sybase, Ingress, MySQL, Teradata (this result is OK):*
> 0 0
> 1 1
> ...
> 10 10
> 11 11
> ...
> 100 00
> 101 01
> *Oracle:*
> 0 <null>
> 1 <null>
> 2 <null>
> ...
> 10 10
> 11 11
> ...
> 100 00
> 101 01
> *Postgres:*
> 0 0
> 1 1
> 2 2
> ...
> 10 10
> 11 11
> ...
> 100 100
> 101 101
> *DB2:*
> 0 " "
> 1 " "
> 2 " "
> ...
> 10 " "
> 11 " "
> ...
> 100 " "
> 101 " "
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (TEIID-3474) Inconsistent results of RIGHT function for different datasources
by Juraj Duráni (JIRA)
[ https://issues.jboss.org/browse/TEIID-3474?page=com.atlassian.jira.plugin... ]
Juraj Duráni edited comment on TEIID-3474 at 6/2/15 1:42 AM:
-------------------------------------------------------------
Maybe another interesting case:
teradata:
*SELECT doublenum, RIGHT(doublenum, 1), cast(doublenum as string) FROM bqt1.smalla ORDER BY intkey*
-24 | 1 | -2.40000000000000E 001
-23 | 1 | -2.30000000000000E 001
...
was (Author: jdurani):
Maybe another interesting case:
teradata:
*SELECT doublenum, RIGHT(doublenum, 1), cast(doublenum as string) FROM bqt1.smalla ORDER BY intkey*
-24 1 -2.40000000000000E 001
-23 1 -2.30000000000000E 001
...
> Inconsistent results of RIGHT function for different datasources
> ----------------------------------------------------------------
>
> Key: TEIID-3474
> URL: https://issues.jboss.org/browse/TEIID-3474
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Connector
> Affects Versions: 7.7
> Environment: OS: Fedora 20
> arch: x86_64
> java: oracle 1.8
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
> Fix For: 8.7.1.6_2, 8.11
>
>
> The RIGHT function returns different results for different datasources. Some of those results are inconsistent with definition of the RIGHT(x,y) function.
> =======
> +*Query: SELECT intkey, RIGHT(intkey, 1) FROM table ORDER BY intkey*+
> *Teradata, SQLServer, Sybase, Ingres, MySQL, Oracle (this result is OK):*
> 0 0
> 1 1
> 2 2
> ...
> 10 0
> 11 1
> ...
> 100 0
> 101 1
> *Postgres:*
> 0 0
> 1 1
> 2 2
> ...
> 10 10
> 11 11
> ...
> 100 100
> 101 101
> *DB2:*
> 0 " "
> 1 " "
> 2 " "
> ...
> 10 " "
> 11 " "
> ...
> 100 " "
> 101 " "
> =====
> +*Query:SELECT intkey, RIGHT(intkey, 2) FROM table ORDER BY intkey*+
> *SQLServer, Sybase, Ingress, MySQL, Teradata (this result is OK):*
> 0 0
> 1 1
> ...
> 10 10
> 11 11
> ...
> 100 00
> 101 01
> *Oracle:*
> 0 <null>
> 1 <null>
> 2 <null>
> ...
> 10 10
> 11 11
> ...
> 100 00
> 101 01
> *Postgres:*
> 0 0
> 1 1
> 2 2
> ...
> 10 10
> 11 11
> ...
> 100 100
> 101 101
> *DB2:*
> 0 " "
> 1 " "
> 2 " "
> ...
> 10 " "
> 11 " "
> ...
> 100 " "
> 101 " "
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (TEIID-3036) Update CXF to current version (3.0.0)
by Gary Gregory (JIRA)
[ https://issues.jboss.org/browse/TEIID-3036?page=com.atlassian.jira.plugin... ]
Gary Gregory commented on TEIID-3036:
-------------------------------------
Hello again. Now that Teiid 9 is around the corner, I am hoping that we'll get the latest CXF in there. Is that in the works?
> Update CXF to current version (3.0.0)
> -------------------------------------
>
> Key: TEIID-3036
> URL: https://issues.jboss.org/browse/TEIID-3036
> Project: Teiid
> Issue Type: Feature Request
> Components: Embedded
> Affects Versions: 8.8
> Reporter: Gary Gregory
>
> In the same vein as TEIID-3030, we embed CXF and Teiid in our server. We use CXF 2.7.10 and are about to update to 3.0.0. At worse, we'll go to 2.7.11 as an interim step to 3.0.0.
> Teiid embedded delivers CXF 2.6.6 for web services support.
> It would be great if we could get Teiid to the latest and greatest from CXF so we can all live in the same space without being forced to deal with any incompatibilities or class loader hacks.
> Thank you,
> Gary
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (TEIID-3500) execute SYSADMIN.matViewStatus failed cause infinite loop in MaterializationManager JobSchedular
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3500?page=com.atlassian.jira.plugin... ]
Kylin Soong edited comment on TEIID-3500 at 6/1/15 9:36 PM:
------------------------------------------------------------
Thanks Steven, you are right. Actually I use the MariaDB(I just thought it's same as mysql), from table in [1], MariaDB will silently map the 'Long' to 'MEDIUMTEXT', but from our document [2], we have to create a status table, the status table have 2 long column, we may add a note in our documents.
[1] https://mariadb.com/kb/en/mariadb/silent-column-changes/
[2] https://docs.jboss.org/author/display/TEIID/External+Materialization
was (Author: kylin):
Thanks Steven, you are right, from table in [1], MariaDB will silently map the 'Long' to 'MEDIUMTEXT', but from our document [2], we have to create a status table, the status table have 2 long column, we may add a note in our documents.
[1] https://mariadb.com/kb/en/mariadb/silent-column-changes/
[2] https://docs.jboss.org/author/display/TEIID/External+Materialization
> execute SYSADMIN.matViewStatus failed cause infinite loop in MaterializationManager JobSchedular
> ------------------------------------------------------------------------------------------------
>
> Key: TEIID-3500
> URL: https://issues.jboss.org/browse/TEIID-3500
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.11
> Reporter: Kylin Soong
> Attachments: ExternalMaterializationMysql.java, mat-mysql-vdb-debug.xml, mat-mysql-vdb.xml, schema.sql
>
>
> While using Mysql, SYSADMIN.matViewStatus throw a SQLExecption
> ~~~
> java.sql.SQLException: org.teiid.api.exception.query.QueryProcessingException: TEIID30168 Couldn't execute the dynamic SQL command "EXECUTE IMMEDIATE (('SELECT TargetSchemaName, TargetName, Valid, LoadState, Updated, Cardinality, LoadNumber, VARIABLES.action FROM ' || VARIABLES.statusTable) || crit) AS TargetSchemaName string, TargetName string, Valid boolean, LoadState string, Updated timestamp, Cardinality long, LoadNumber long, OnErrorAction string USING vdbName = VARIABLES.vdbName, vdbVersion = VARIABLES.vdbVersion, schemaName = matViewStatus.schemaName, viewName = matViewStatus.viewName" with the SQL statement "(('SELECT TargetSchemaName, TargetName, Valid, LoadState, Updated, Cardinality, LoadNumber, VARIABLES.action FROM ' || VARIABLES.statusTable) || crit)" due to: The datatype 'clob' for element 'Cardinality' in the dynamic SQL cannot be implicitly converted to 'long'.
> ~~~
> this cause scheduleJob infinite loop, 'SYSADMIN.loadMatView' never be executed.
> If we didn't configure 'teiid_rel:MATVIEW_TTL', execute SYSADMIN.matViewStatus manually , full stack trace as [1]
> If test with H2 database, SYSADMIN.matViewStatus works fine.
> [1] stack trace
> ~~~
> 2015-06-01 11:35 088 WARNING [org.teiid.PROCESSOR] (main) TEIID30020 Processing exception for request gQ25UW2DqodQ.7 'TEIID30168 Couldn't execute the dynamic SQL command "EXECUTE IMMEDIATE (('SELECT TargetSchemaName, TargetName, Valid, LoadState, Updated, Cardinality, LoadNumber, VARIABLES.action FROM ' || VARIABLES.statusTable) || crit) AS TargetSchemaName string, TargetName string, Valid boolean, LoadState string, Updated timestamp, Cardinality long, LoadNumber long, OnErrorAction string USING vdbName = VARIABLES.vdbName, vdbVersion = VARIABLES.vdbVersion, schemaName = matViewStatus.schemaName, viewName = matViewStatus.viewName" with the SQL statement "(('SELECT TargetSchemaName, TargetName, Valid, LoadState, Updated, Cardinality, LoadNumber, VARIABLES.action FROM ' || VARIABLES.statusTable) || crit)" due to: The datatype 'clob' for element 'Cardinality' in the dynamic SQL cannot be implicitly converted to 'long'.'. Originally QueryProcessingException ExecDynamicSqlInstruction.java:341. Enable more detailed logging to see the entire stacktrace.
> org.teiid.jdbc.TeiidSQLException: TEIID30168 Couldn't execute the dynamic SQL command "EXECUTE IMMEDIATE (('SELECT TargetSchemaName, TargetName, Valid, LoadState, Updated, Cardinality, LoadNumber, VARIABLES.action FROM ' || VARIABLES.statusTable) || crit) AS TargetSchemaName string, TargetName string, Valid boolean, LoadState string, Updated timestamp, Cardinality long, LoadNumber long, OnErrorAction string USING vdbName = VARIABLES.vdbName, vdbVersion = VARIABLES.vdbVersion, schemaName = matViewStatus.schemaName, viewName = matViewStatus.viewName" with the SQL statement "(('SELECT TargetSchemaName, TargetName, Valid, LoadState, Updated, Cardinality, LoadNumber, VARIABLES.action FROM ' || VARIABLES.statusTable) || crit)" due to: The datatype 'clob' for element 'Cardinality' in the dynamic SQL cannot be implicitly converted to 'long'.
> at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:135)
> at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:71)
> at org.teiid.jdbc.StatementImpl.postReceiveResults(StatementImpl.java:694)
> at org.teiid.jdbc.StatementImpl.access$100(StatementImpl.java:64)
> at org.teiid.jdbc.StatementImpl$2.onCompletion(StatementImpl.java:533)
> at org.teiid.client.util.ResultsFuture.addCompletionListener(ResultsFuture.java:148)
> at org.teiid.jdbc.StatementImpl.executeSql(StatementImpl.java:529)
> at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:1062)
> at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:314)
> at org.teiid.example.util.JDBCUtils.execute(JDBCUtils.java:86)
> at org.teiid.test.perf.ExternalMaterializationMysqlDebug.executeMatViewStatus(ExternalMaterializationMysqlDebug.java:83)
> at org.teiid.test.perf.ExternalMaterializationMysqlDebug.main(ExternalMaterializationMysqlDebug.java:65)
> Caused by: org.teiid.api.exception.query.QueryProcessingException: TEIID30168 Couldn't execute the dynamic SQL command "EXECUTE IMMEDIATE (('SELECT TargetSchemaName, TargetName, Valid, LoadState, Updated, Cardinality, LoadNumber, VARIABLES.action FROM ' || VARIABLES.statusTable) || crit) AS TargetSchemaName string, TargetName string, Valid boolean, LoadState string, Updated timestamp, Cardinality long, LoadNumber long, OnErrorAction string USING vdbName = VARIABLES.vdbName, vdbVersion = VARIABLES.vdbVersion, schemaName = matViewStatus.schemaName, viewName = matViewStatus.viewName" with the SQL statement "(('SELECT TargetSchemaName, TargetName, Valid, LoadState, Updated, Cardinality, LoadNumber, VARIABLES.action FROM ' || VARIABLES.statusTable) || crit)" due to: The datatype 'clob' for element 'Cardinality' in the dynamic SQL cannot be implicitly converted to 'long'.
> at org.teiid.query.processor.proc.ExecDynamicSqlInstruction.process(ExecDynamicSqlInstruction.java:249)
> at org.teiid.query.processor.proc.ProcedurePlan.processProcedure(ProcedurePlan.java:384)
> at org.teiid.query.processor.proc.ProcedurePlan.nextBatchDirect(ProcedurePlan.java:293)
> at org.teiid.query.processor.proc.ProcedurePlan.nextBatch(ProcedurePlan.java:267)
> at org.teiid.query.processor.relational.PlanExecutionNode.nextBatchDirect(PlanExecutionNode.java:118)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278)
> at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:148)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278)
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:145)
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151)
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146)
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:457)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:339)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:267)
> at org.teiid.dqp.internal.process.DQPCore.executeRequest(DQPCore.java:298)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.teiid.transport.LocalServerConnection$1$1.call(LocalServerConnection.java:175)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:260)
> at org.teiid.transport.LocalServerConnection$1.invoke(LocalServerConnection.java:173)
> at com.sun.proxy.$Proxy11.executeRequest(Unknown Source)
> at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:661)
> at org.teiid.jdbc.StatementImpl.executeSql(StatementImpl.java:527)
> ... 5 more
> Caused by: org.teiid.api.exception.query.QueryProcessingException: The datatype 'clob' for element 'Cardinality' in the dynamic SQL cannot be implicitly converted to 'long'.
> at org.teiid.query.processor.proc.ExecDynamicSqlInstruction.validateDynamicCommand(ExecDynamicSqlInstruction.java:341)
> at org.teiid.query.processor.proc.ExecDynamicSqlInstruction.process(ExecDynamicSqlInstruction.java:168)
> ... 34 more
> ~~~
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (TEIID-3500) execute SYSADMIN.matViewStatus failed cause infinite loop in MaterializationManager JobSchedular
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3500?page=com.atlassian.jira.plugin... ]
Kylin Soong commented on TEIID-3500:
------------------------------------
Thanks Steven, you are right, from table in [1], MariaDB will silently map the 'Long' to 'MEDIUMTEXT', but from our document [2], we have to create a status table, the status table have 2 long column, we may add a note in our documents.
[1] https://mariadb.com/kb/en/mariadb/silent-column-changes/
[2] https://docs.jboss.org/author/display/TEIID/External+Materialization
> execute SYSADMIN.matViewStatus failed cause infinite loop in MaterializationManager JobSchedular
> ------------------------------------------------------------------------------------------------
>
> Key: TEIID-3500
> URL: https://issues.jboss.org/browse/TEIID-3500
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.11
> Reporter: Kylin Soong
> Attachments: ExternalMaterializationMysql.java, mat-mysql-vdb-debug.xml, mat-mysql-vdb.xml, schema.sql
>
>
> While using Mysql, SYSADMIN.matViewStatus throw a SQLExecption
> ~~~
> java.sql.SQLException: org.teiid.api.exception.query.QueryProcessingException: TEIID30168 Couldn't execute the dynamic SQL command "EXECUTE IMMEDIATE (('SELECT TargetSchemaName, TargetName, Valid, LoadState, Updated, Cardinality, LoadNumber, VARIABLES.action FROM ' || VARIABLES.statusTable) || crit) AS TargetSchemaName string, TargetName string, Valid boolean, LoadState string, Updated timestamp, Cardinality long, LoadNumber long, OnErrorAction string USING vdbName = VARIABLES.vdbName, vdbVersion = VARIABLES.vdbVersion, schemaName = matViewStatus.schemaName, viewName = matViewStatus.viewName" with the SQL statement "(('SELECT TargetSchemaName, TargetName, Valid, LoadState, Updated, Cardinality, LoadNumber, VARIABLES.action FROM ' || VARIABLES.statusTable) || crit)" due to: The datatype 'clob' for element 'Cardinality' in the dynamic SQL cannot be implicitly converted to 'long'.
> ~~~
> this cause scheduleJob infinite loop, 'SYSADMIN.loadMatView' never be executed.
> If we didn't configure 'teiid_rel:MATVIEW_TTL', execute SYSADMIN.matViewStatus manually , full stack trace as [1]
> If test with H2 database, SYSADMIN.matViewStatus works fine.
> [1] stack trace
> ~~~
> 2015-06-01 11:35 088 WARNING [org.teiid.PROCESSOR] (main) TEIID30020 Processing exception for request gQ25UW2DqodQ.7 'TEIID30168 Couldn't execute the dynamic SQL command "EXECUTE IMMEDIATE (('SELECT TargetSchemaName, TargetName, Valid, LoadState, Updated, Cardinality, LoadNumber, VARIABLES.action FROM ' || VARIABLES.statusTable) || crit) AS TargetSchemaName string, TargetName string, Valid boolean, LoadState string, Updated timestamp, Cardinality long, LoadNumber long, OnErrorAction string USING vdbName = VARIABLES.vdbName, vdbVersion = VARIABLES.vdbVersion, schemaName = matViewStatus.schemaName, viewName = matViewStatus.viewName" with the SQL statement "(('SELECT TargetSchemaName, TargetName, Valid, LoadState, Updated, Cardinality, LoadNumber, VARIABLES.action FROM ' || VARIABLES.statusTable) || crit)" due to: The datatype 'clob' for element 'Cardinality' in the dynamic SQL cannot be implicitly converted to 'long'.'. Originally QueryProcessingException ExecDynamicSqlInstruction.java:341. Enable more detailed logging to see the entire stacktrace.
> org.teiid.jdbc.TeiidSQLException: TEIID30168 Couldn't execute the dynamic SQL command "EXECUTE IMMEDIATE (('SELECT TargetSchemaName, TargetName, Valid, LoadState, Updated, Cardinality, LoadNumber, VARIABLES.action FROM ' || VARIABLES.statusTable) || crit) AS TargetSchemaName string, TargetName string, Valid boolean, LoadState string, Updated timestamp, Cardinality long, LoadNumber long, OnErrorAction string USING vdbName = VARIABLES.vdbName, vdbVersion = VARIABLES.vdbVersion, schemaName = matViewStatus.schemaName, viewName = matViewStatus.viewName" with the SQL statement "(('SELECT TargetSchemaName, TargetName, Valid, LoadState, Updated, Cardinality, LoadNumber, VARIABLES.action FROM ' || VARIABLES.statusTable) || crit)" due to: The datatype 'clob' for element 'Cardinality' in the dynamic SQL cannot be implicitly converted to 'long'.
> at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:135)
> at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:71)
> at org.teiid.jdbc.StatementImpl.postReceiveResults(StatementImpl.java:694)
> at org.teiid.jdbc.StatementImpl.access$100(StatementImpl.java:64)
> at org.teiid.jdbc.StatementImpl$2.onCompletion(StatementImpl.java:533)
> at org.teiid.client.util.ResultsFuture.addCompletionListener(ResultsFuture.java:148)
> at org.teiid.jdbc.StatementImpl.executeSql(StatementImpl.java:529)
> at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:1062)
> at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:314)
> at org.teiid.example.util.JDBCUtils.execute(JDBCUtils.java:86)
> at org.teiid.test.perf.ExternalMaterializationMysqlDebug.executeMatViewStatus(ExternalMaterializationMysqlDebug.java:83)
> at org.teiid.test.perf.ExternalMaterializationMysqlDebug.main(ExternalMaterializationMysqlDebug.java:65)
> Caused by: org.teiid.api.exception.query.QueryProcessingException: TEIID30168 Couldn't execute the dynamic SQL command "EXECUTE IMMEDIATE (('SELECT TargetSchemaName, TargetName, Valid, LoadState, Updated, Cardinality, LoadNumber, VARIABLES.action FROM ' || VARIABLES.statusTable) || crit) AS TargetSchemaName string, TargetName string, Valid boolean, LoadState string, Updated timestamp, Cardinality long, LoadNumber long, OnErrorAction string USING vdbName = VARIABLES.vdbName, vdbVersion = VARIABLES.vdbVersion, schemaName = matViewStatus.schemaName, viewName = matViewStatus.viewName" with the SQL statement "(('SELECT TargetSchemaName, TargetName, Valid, LoadState, Updated, Cardinality, LoadNumber, VARIABLES.action FROM ' || VARIABLES.statusTable) || crit)" due to: The datatype 'clob' for element 'Cardinality' in the dynamic SQL cannot be implicitly converted to 'long'.
> at org.teiid.query.processor.proc.ExecDynamicSqlInstruction.process(ExecDynamicSqlInstruction.java:249)
> at org.teiid.query.processor.proc.ProcedurePlan.processProcedure(ProcedurePlan.java:384)
> at org.teiid.query.processor.proc.ProcedurePlan.nextBatchDirect(ProcedurePlan.java:293)
> at org.teiid.query.processor.proc.ProcedurePlan.nextBatch(ProcedurePlan.java:267)
> at org.teiid.query.processor.relational.PlanExecutionNode.nextBatchDirect(PlanExecutionNode.java:118)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278)
> at org.teiid.query.processor.relational.ProjectNode.nextBatchDirect(ProjectNode.java:148)
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278)
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:145)
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151)
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:164)
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:146)
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:457)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:339)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:267)
> at org.teiid.dqp.internal.process.DQPCore.executeRequest(DQPCore.java:298)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.teiid.transport.LocalServerConnection$1$1.call(LocalServerConnection.java:175)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:276)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:260)
> at org.teiid.transport.LocalServerConnection$1.invoke(LocalServerConnection.java:173)
> at com.sun.proxy.$Proxy11.executeRequest(Unknown Source)
> at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:661)
> at org.teiid.jdbc.StatementImpl.executeSql(StatementImpl.java:527)
> ... 5 more
> Caused by: org.teiid.api.exception.query.QueryProcessingException: The datatype 'clob' for element 'Cardinality' in the dynamic SQL cannot be implicitly converted to 'long'.
> at org.teiid.query.processor.proc.ExecDynamicSqlInstruction.validateDynamicCommand(ExecDynamicSqlInstruction.java:341)
> at org.teiid.query.processor.proc.ExecDynamicSqlInstruction.process(ExecDynamicSqlInstruction.java:168)
> ... 34 more
> ~~~
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (TEIID-3503) Use of ModelMetaData required teiid-admin jar
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3503?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3503:
---------------------------------------
If you create a new project that simply reference teiid-runtime for example:
{code}
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<artifactId>foo</artifactId>
<groupId>bar</groupId>
<version>1</version>
<name>x</name>
<description>y</description>
<dependencies>
<dependency>
<groupId>org.jboss.teiid</groupId>
<artifactId>teiid-runtime</artifactId>
<version>8.11.0.Beta4-SNAPSHOT</version>
</dependency>
</dependencies>
</project>
{code}
And do a mvn install without having the early access / preview repos accessible, it will fail to fully resolve the teiid-runtime dependency (as we pull other dependency info, such as jgroups, from EAP). So we need to provide more guidance, which I haven't experimented around yet with a bom with version overrides and/or excludes, to have an embedded that's truly free of EAP.
> Use of ModelMetaData required teiid-admin jar
> ---------------------------------------------
>
> Key: TEIID-3503
> URL: https://issues.jboss.org/browse/TEIID-3503
> Project: Teiid
> Issue Type: Quality Risk
> Components: Embedded
> Affects Versions: 8.10
> Reporter: Michael Davies
> Assignee: Ramesh Reddy
> Priority: Minor
> Labels: CR1
> Fix For: 8.11
>
>
> We are using Embedded and specifically ModelMetaData, for specifying VDB.
> ModelMetaData class comes from teiid-admin project, which pulls in a lot of AS dependencies, some of which are only available from earlyrelease maven repo.
> For example - org.jboss.as:jboss-as-parent:pom:7.4.0.Final-redhat-4
> So essentially users developing against released teiid API (using ModelMetaData) now have dependency on earlyaccess repo.
> Where I work the people who manage the internal company repo do not like proxying non-release repos, and so this causes a bit of a pain.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (TEIID-3503) Use of ModelMetaData required teiid-admin jar
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3503?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-3503:
-------------------------------------
The parent pom has references to version of the EAP in property. The dependencies are defined in the <dependencyManagement> not in <dependency>, so not sure how this will affect the pulling in dependencies for embedded. May be maven is somehow obscurely adds this in, may be you guys can explain little further.
My primary goal for JIRA for was not pull in EAP transitive dependencies when one mentions the dependency on "admin" module. I think that can be achieved with the code changes.
Certainly we can not remove "earlyaccess" completely from the Teiid build until move down to WildFly based deployments. or build a new module structure that removes all the jboss eap specific dependencies to a separate repo along side the core teiid code.
> Use of ModelMetaData required teiid-admin jar
> ---------------------------------------------
>
> Key: TEIID-3503
> URL: https://issues.jboss.org/browse/TEIID-3503
> Project: Teiid
> Issue Type: Quality Risk
> Components: Embedded
> Affects Versions: 8.10
> Reporter: Michael Davies
> Assignee: Ramesh Reddy
> Priority: Minor
> Labels: CR1
> Fix For: 8.11
>
>
> We are using Embedded and specifically ModelMetaData, for specifying VDB.
> ModelMetaData class comes from teiid-admin project, which pulls in a lot of AS dependencies, some of which are only available from earlyrelease maven repo.
> For example - org.jboss.as:jboss-as-parent:pom:7.4.0.Final-redhat-4
> So essentially users developing against released teiid API (using ModelMetaData) now have dependency on earlyaccess repo.
> Where I work the people who manage the internal company repo do not like proxying non-release repos, and so this causes a bit of a pain.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (TEIID-3504) Null pointer exception executing dynamic sql
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3504?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-3504.
-----------------------------------
Resolution: Done
Modified the clone to return a copy.
> Null pointer exception executing dynamic sql
> --------------------------------------------
>
> Key: TEIID-3504
> URL: https://issues.jboss.org/browse/TEIID-3504
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.7
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.11
>
>
> When a procedure with dynamic sql is rerun the cloning of the group context allows for the same linked list to be modified by multiple threads leading to errors, which typically resemble a null pointer exception (for example at QueryResolver line 259 due to a null group). The cloning also allows for the group context groups to grow in number as the locally scoped groups are re-added.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (TEIID-3503) Use of ModelMetaData required teiid-admin jar
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3503?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3503:
---------------------------------------
> This should remove the earlyaccess maven repo type transitive dependencies for the embedded.
Not quite yet. Our parent pom references EAP, so you'll hit this even with the restructuring.
> Use of ModelMetaData required teiid-admin jar
> ---------------------------------------------
>
> Key: TEIID-3503
> URL: https://issues.jboss.org/browse/TEIID-3503
> Project: Teiid
> Issue Type: Quality Risk
> Components: Embedded
> Affects Versions: 8.10
> Reporter: Michael Davies
> Assignee: Ramesh Reddy
> Priority: Minor
> Labels: CR1
> Fix For: 8.11
>
>
> We are using Embedded and specifically ModelMetaData, for specifying VDB.
> ModelMetaData class comes from teiid-admin project, which pulls in a lot of AS dependencies, some of which are only available from earlyrelease maven repo.
> For example - org.jboss.as:jboss-as-parent:pom:7.4.0.Final-redhat-4
> So essentially users developing against released teiid API (using ModelMetaData) now have dependency on earlyaccess repo.
> Where I work the people who manage the internal company repo do not like proxying non-release repos, and so this causes a bit of a pain.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (TEIID-3503) Use of ModelMetaData required teiid-admin jar
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-3503?page=com.atlassian.jira.plugin... ]
Ramesh Reddy resolved TEIID-3503.
---------------------------------
Labels: CR1 (was: )
Fix Version/s: 8.11
Resolution: Done
Introduced a new module called "jboss-admin" and moved the JBoss specific classes and their dependencies to this module. Now only "jboss-integration" and "test-integration" depend on this new "jboss-admin" module, rest others will keep using the "admin" as before.
This should remove the earlyaccess maven repo type transitive dependencies for the embedded.
Checked for kitting and runtime errors.
> Use of ModelMetaData required teiid-admin jar
> ---------------------------------------------
>
> Key: TEIID-3503
> URL: https://issues.jboss.org/browse/TEIID-3503
> Project: Teiid
> Issue Type: Quality Risk
> Components: Embedded
> Affects Versions: 8.10
> Reporter: Michael Davies
> Assignee: Ramesh Reddy
> Priority: Minor
> Labels: CR1
> Fix For: 8.11
>
>
> We are using Embedded and specifically ModelMetaData, for specifying VDB.
> ModelMetaData class comes from teiid-admin project, which pulls in a lot of AS dependencies, some of which are only available from earlyrelease maven repo.
> For example - org.jboss.as:jboss-as-parent:pom:7.4.0.Final-redhat-4
> So essentially users developing against released teiid API (using ModelMetaData) now have dependency on earlyaccess repo.
> Where I work the people who manage the internal company repo do not like proxying non-release repos, and so this causes a bit of a pain.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months