[JBoss JIRA] (TEIID-3141) Bad result of query with GROUB BY clause (underlying sybase15 datasource)
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3141?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3141.
---------------------------------
> Bad result of query with GROUB BY clause (underlying sybase15 datasource)
> -------------------------------------------------------------------------
>
> Key: TEIID-3141
> URL: https://issues.jboss.org/browse/TEIID-3141
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.7.1
> Environment: OS: fedora20
> arch: x86_64
> java: sun 1.7
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
>
> Description:
> There is sybase15 database with table named SmallA and table named SmallA in VDB which is mapped to sybase table (see tables definition below).
> I am trying to run query against VDB:
> SELECT
> INTKEY, STRINGKEY, INTNUM, STRINGNUM, FLOATNUM, LONGNUM, DOUBLENUM, BYTENUM, DATEVALUE, TIMEVALUE, TIMESTAMPVALUE, BOOLEANVALUE, CHARVALUE, SHORTVALUE, BIGINTEGERVALUE, BIGDECIMALVALUE
> FROM
> BQT1.SMALLA
> GROUP BY
> INTKEY, STRINGKEY, INTNUM, STRINGNUM, FLOATNUM, LONGNUM, DOUBLENUM, BYTENUM, DATEVALUE, TIMEVALUE, TIMESTAMPVALUE, BOOLEANVALUE, CHARVALUE, SHORTVALUE, BIGINTEGERVALUE, BIGDECIMALVALUE
> Result is table which misses some values (the other values are OK):
> FloatNum: always 0
> ByteNum: always 0
> DateValue: always 1900-01-01
> TimeValue: always 00:00:00
> BooleanValue: always 'false'
> CharValue: always empty character
> ShortValue: always 0
> BigIntegerValue: always 0
> BigDecimalValue: always 0
> After removing 'INTKEY' and 'STRINGKEY' from the query is result OK (sybase15 has indices only for these two columns).
> ///////////////////
> Table definition
> ///////////////////
> SmallA (sybase) has these columns (name:type):
> IntKey:int -> PRIMARY KEY, HAS INDEX
> StringKey:varchar -> HAS INDEX
> IntNum:int
> StringNum:varchar
> FloatNum:float
> LongNum:numeric
> DoubleNum:float
> ByteNum:real
> DateValue:datetime
> TimeValue:datetime
> TimestampValue:datetime
> BooleanValue:tinyint
> CharValue:char
> ShortValue:numeric
> BigIntegerValue:numeric
> BigDecimalValue:numeric
> ObjectValue:text
> SmallA (VDB) has these columns (name:type):
> IntKey:integer
> StringKey:string
> IntNum:integer
> StringNum:string
> FloatNum:float
> LongNum:long
> DoubleNum:double
> ByteNum:byte
> DateValue:date
> TimeValue:time
> TimestampValue:timestamp
> BooleanValue:boolean
> CharValue:char
> ShortValue:short
> BigIntegerValue:biginteger
> BigDecimalValue:bigdecimal
> ObjectValue:object
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (TEIID-3904) TEIID31100 Parsing error: Encountered "[*]move[*] backward 5831" on openquery update command
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3904?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3904.
---------------------------------
> TEIID31100 Parsing error: Encountered "[*]move[*] backward 5831" on openquery update command
> --------------------------------------------------------------------------------------------
>
> Key: TEIID-3904
> URL: https://issues.jboss.org/browse/TEIID-3904
> Project: Teiid
> Issue Type: Bug
> Components: ODBC
> Affects Versions: 8.7.1.6_2
> Environment: Red Hat JBoss Data Virtualization 6.2 on EAP6.4.0 patched to version 6.4.3,
> JBoss Developer Studio 8.1.0GA with Teiid Designer plugin 9.0.3.Final.v20150810-1438-B1157
> 64-bit Windows 7 environment
> Reporter: Steve Tran
> Assignee: Steven Hawkins
> Fix For: 8.13
>
> Attachments: ODBC_SNIP.PNG
>
>
> Getting an error when attempting to update an Oracle Table that was virtualized in JDV.
> Here's the query
> update A
> set do_not_use = 1
> FROM OPENQUERY(HSI, 'SELECT * FROM hsi_DW_ebl.hsi_tm_pd where do_not_use is null') A
> where do_not_use is null;
> {code}
> [Server:cdtssoa126d-jdv-one] 21:14:35,311 WARN [org.teiid.ODBC] (Worker975_QueryProcessorQueue8734224) TEIID40020 Error occurred: org.teiid.jdbc.TeiidSQLException: TEIID31100 Parsing error: Encountered "[*]move[*] backward 5831" at line 1, column 1.
> [Server:cdtssoa126d-jdv-one] Was expecting: "alter" | "begin" | "call" | "create" | "delete" | "drop" | "exec" | "execute" | "insert" | "merge" ...
> [Server:cdtssoa126d-jdv-one] at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:135) [teiid-client-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> [Server:cdtssoa126d-jdv-one] at org.teiid.jdbc.TeiidSQLException.create(TeiidSQLException.java:71) [teiid-client-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> [Server:cdtssoa126d-jdv-one] at org.teiid.jdbc.StatementImpl.postReceiveResults(StatementImpl.java:667) [teiid-client-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> [Server:cdtssoa126d-jdv-one] at org.teiid.jdbc.StatementImpl.access$100(StatementImpl.java:63) [teiid-client-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> [Server:cdtssoa126d-jdv-one] at org.teiid.jdbc.StatementImpl$2.onCompletion(StatementImpl.java:515) [teiid-client-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> [Server:cdtssoa126d-jdv-one] at org.teiid.client.util.ResultsFuture.done(ResultsFuture.java:135) [teiid-client-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> [Server:cdtssoa126d-jdv-one] at org.teiid.client.util.ResultsFuture.access$200(ResultsFuture.java:40) [teiid-client-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> [Server:cdtssoa126d-jdv-one] at org.teiid.client.util.ResultsFuture$1.receiveResults(ResultsFuture.java:79) [teiid-client-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> [Server:cdtssoa126d-jdv-one] at org.teiid.dqp.internal.process.RequestWorkItem.sendError(RequestWorkItem.java:1001) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> [Server:cdtssoa126d-jdv-one] at org.teiid.dqp.internal.process.RequestWorkItem.close(RequestWorkItem.java:556) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> [Server:cdtssoa126d-jdv-one] at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:352) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> [Server:cdtssoa126d-jdv-one] at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> [Server:cdtssoa126d-jdv-one] at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:254) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> [Server:cdtssoa126d-jdv-one] at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:274) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> [Server:cdtssoa126d-jdv-one] at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> [Server:cdtssoa126d-jdv-one] at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> [Server:cdtssoa126d-jdv-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_75]
> [Server:cdtssoa126d-jdv-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_75]
> [Server:cdtssoa126d-jdv-one] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_75]
> [Server:cdtssoa126d-jdv-one] Caused by: org.teiid.api.exception.query.QueryParserException: TEIID31100 Parsing error: Encountered "[*]move[*] backward 5831" at line 1, column 1.
> [Server:cdtssoa126d-jdv-one] Was expecting: "alter" | "begin" | "call" | "create" | "delete" | "drop" | "exec" | "execute" | "insert" | "merge" ...
> [Server:cdtssoa126d-jdv-one] at org.teiid.query.parser.QueryParser.convertParserException(QueryParser.java:214) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> [Server:cdtssoa126d-jdv-one] at org.teiid.query.parser.QueryParser.parseCommand(QueryParser.java:164) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> [Server:cdtssoa126d-jdv-one] at org.teiid.query.parser.QueryParser.parseCommand(QueryParser.java:140) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> [Server:cdtssoa126d-jdv-one] at org.teiid.dqp.internal.process.Request.parseCommand(Request.java:279) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> [Server:cdtssoa126d-jdv-one] at org.teiid.dqp.internal.process.Request.generatePlan(Request.java:363) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> [Server:cdtssoa126d-jdv-one] at org.teiid.dqp.internal.process.Request.processRequest(Request.java:435) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> [Server:cdtssoa126d-jdv-one] at org.teiid.dqp.internal.process.RequestWorkItem.processNew(RequestWorkItem.java:613) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> [Server:cdtssoa126d-jdv-one] at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:315) [teiid-engine-8.7.1.6_2-redhat-6.jar:8.7.1.6_2-redhat-6]
> [Server:cdtssoa126d-jdv-one] ... 8 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (TEIID-3982) BlockedException throw twice for each Query
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3982?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3982.
---------------------------------
> BlockedException throw twice for each Query
> -------------------------------------------
>
> Key: TEIID-3982
> URL: https://issues.jboss.org/browse/TEIID-3982
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine
> Affects Versions: 9.x
> Reporter: Kylin Soong
> Assignee: Steven Hawkins
>
> I have met a question while I was runing [embedded-portfolio](https://github.com/teiid/teiid-embedded-examples/tree... example, Even the Query can get result correctly, but each query can cause BlockedException throw 2 times, a DEBUG log be recorded 2 times for each query:
> {code}
> 2016-02-18 14:58 754 DEBUG [org.teiid.PROCESSOR] (main) Request Thread 2Py78gPmtfcm.0 - processor blocked
> 2016-02-18 14:58 930 DEBUG [org.teiid.PROCESSOR] (main) Request Thread 2Py78gPmtfcm.0 - processor blocked
> {code}
> The Exception stack trace in my test looks
> {code}
> org.teiid.common.buffer.BlockedException
> at org.teiid.common.buffer.BlockedException.<clinit>(BlockedException.java:39)
> at org.teiid.query.processor.QueryProcessor.<clinit>(QueryProcessor.java:58)
> at org.teiid.dqp.internal.process.Request.createProcessor(Request.java:334)
> at org.teiid.dqp.internal.process.Request.processRequest(Request.java:465)
> at org.teiid.dqp.internal.process.RequestWorkItem.processNew(RequestWorkItem.java:633)
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:333)
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51)
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:271)
> at org.teiid.dqp.internal.process.DQPCore.executeRequest(DQPCore.java:306)
> at org.teiid.dqp.internal.process.DQPCore.executeRequest(DQPCore.java:238)
> 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:180)
> 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:178)
> at com.sun.proxy.$Proxy11.executeRequest(Unknown Source)
> at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:670)
> at org.teiid.jdbc.StatementImpl.executeSql(StatementImpl.java:536)
> at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:1073)
> at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:323)
> at org.teiid.example.util.JDBCUtils.execute(JDBCUtils.java:85)
> at org.teiid.test.embedded.process.TeiidEmbeddedPortfolioProcess.main(TeiidEmbeddedPortfolioProcess.java:58)
> {code}
> h3. Further investigation
> As [1], around line 350,
> {code}
> } catch (BlockedException e) {
> e.printStackTrace();
> if (LogManager.isMessageToBeRecorded(LogConstants.CTX_DQP, MessageLevel.DETAIL)) {
> LogManager.logDetail(LogConstants.CTX_DQP, "Request Thread", requestID, "- processor blocked"); //$NON-NLS-1$ //$NON-NLS-2$
> }
> if (e == BlockedException.BLOCKED_ON_MEMORY_EXCEPTION || e instanceof ExpiredTimeSliceException) {
> //requeue
> this.moreWork();
> }
> }
> {code}
> Why each query need block processor 2 times?
> [1] https://github.com/teiid/teiid/blob/master/engine/src/main/java/org/teiid...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (TEIID-3947) Incorrect handling of text cells carrying pure numerals in Excel translator
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3947?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-3947.
---------------------------------
> Incorrect handling of text cells carrying pure numerals in Excel translator
> ---------------------------------------------------------------------------
>
> Key: TEIID-3947
> URL: https://issues.jboss.org/browse/TEIID-3947
> Project: Teiid
> Issue Type: Quality Risk
> Components: Misc. Connectors
> Reporter: Vijay Bhaskar Chintalapati
> Assignee: Steven Hawkins
> Priority: Minor
>
> When the user intends to retrieve (based on source model) textual data from a column in an Excel spreadsheet and when one or of the cells are pure numbers, what gets returned is the string representation of the double representation of the number.
> For example: If the cell has 1234, instead of returning 1234 Apache POI and DV returns 1234.0
> Adding more detail below from a Email sent as part of client update:
> After a thorough investigation into the issue it was found that JDV relies on Apache POI APIs to get the cell content . According to the link [1], Apache POI will return the cell type as double by default when asked for the cell type and when asked for the value will return the double value. JDV is doing its due diligence of converting the value to String [2] but by then POI has already returned 11.0 for a cell value of 11. And converting 11.0 to String will still keep it at
> 11.0.
> What should ideally happen, in my opinion is, the double should be compared against its Long equivalent and see if they are the same. If Yes, then the cell value should be extracted as string disregarding the type associated with the cell. This is because regardless of how you try to maintain a cell text value of 11.0, Excel always saves (don't confuse this with how it shows) it as 11.
> [1] https://poi.apache.org/apidocs/org/apache/poi/ss/usermodel/Cell.html
> [2] https://goo.gl/nC3XoG
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months