July 2015 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-3596) Command logging: last command's log is not ended

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3596?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-3596: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1247633 > Command logging: last command's log is not ended > ------------------------------------------------ > > Key: TEIID-3596 > URL: https://issues.jboss.org/browse/TEIID-3596 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.7.1.6_2 > Reporter: Jan Stastny > Assignee: Steven Hawkins > > There are incomplete entries when performing queries on some vdb and examining the org.teiid.COMMAND_LOG entries in server.log. > From the logs it seems, that the closing entry for a user command is not logged until either another command is performed or the server is shut down. > The following logs appears right after the command is performed: > {code:plain} > [org.teiid.COMMAND_LOG] (New I/O worker #64) START USER COMMAND: startTime=2015-07-28 13:43:18.441 requestID=rfFDiTxhxLGL.0 txID=null sessionID=rfFDiTxhxLGL applicationName=JDBC principal=user@teiid-security vdbName=Portfolio vdbVersion=1 sql=select * from product > [org.teiid.COMMAND_LOG] (Worker1_QueryProcessorQueue1) START DATA SRC COMMAND: startTime=2015-07-28 13:43:18.54 requestID=rfFDiTxhxLGL.0 sourceCommandID=0 executionID=0 txID=null modelName=Accounts translatorName=translator-h2 sessionID=rfFDiTxhxLGL principal=user@teiid-security sql=SELECT g_0.ID, g_0.SYMBOL, g_0.COMPANY_NAME FROM Accounts.PRODUCT AS g_0 > [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue2) END SRC COMMAND: endTime=2015-07-28 13:43:18.548 requestID=rfFDiTxhxLGL.0 sourceCommandID=0 executionID=0 txID=null modelName=Accounts translatorName=translator-h2 sessionID=rfFDiTxhxLGL principal=user@teiid-security finalRowCount=25 > {code} > while the following appers only when the server is shut down (notice the time difference between this one and preceding ones): > {code:plain} > [org.teiid.COMMAND_LOG] (New I/O worker #64) CANCEL USER COMMAND: endTime=2015-07-28 13:43:29.152 requestID=rfFDiTxhxLGL.0 txID=null sessionID=rfFDiTxhxLGL principal=user@teiid-security vdbName=Portfolio vdbVersion=1 finalRowCount=null > {code} > If there is another command following, the previous command log entry is completed (but it can take even minutes): > {code:plain} > [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue3) END USER COMMAND: endTime=2015-07-28 14:18:59.511 requestID=q97k+Z4gwV64.0 txID=null sessionID=q97k+Z4gwV64 principal=user@teiid-security vdbName=Portfolio vdbVersion=1 finalRowCount=25 > {code} > Also the ending log entry of one command and opening entry of another appear in any order. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3596) Command logging: last command's log is not ended

by Jan Stastny (JIRA)

Jan Stastny created TEIID-3596: ---------------------------------- Summary: Command logging: last command's log is not ended Key: TEIID-3596 URL: https://issues.jboss.org/browse/TEIID-3596 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 8.7.1.6_2 Reporter: Jan Stastny Assignee: Steven Hawkins There are incomplete entries when performing queries on some vdb and examining the org.teiid.COMMAND_LOG entries in server.log. >From the logs it seems, that the closing entry for a user command is not logged until either another command is performed or the server is shut down. The following logs appears right after the command is performed: {code:plain} [org.teiid.COMMAND_LOG] (New I/O worker #64) START USER COMMAND: startTime=2015-07-28 13:43:18.441 requestID=rfFDiTxhxLGL.0 txID=null sessionID=rfFDiTxhxLGL applicationName=JDBC principal=user@teiid-security vdbName=Portfolio vdbVersion=1 sql=select * from product [org.teiid.COMMAND_LOG] (Worker1_QueryProcessorQueue1) START DATA SRC COMMAND: startTime=2015-07-28 13:43:18.54 requestID=rfFDiTxhxLGL.0 sourceCommandID=0 executionID=0 txID=null modelName=Accounts translatorName=translator-h2 sessionID=rfFDiTxhxLGL principal=user@teiid-security sql=SELECT g_0.ID, g_0.SYMBOL, g_0.COMPANY_NAME FROM Accounts.PRODUCT AS g_0 [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue2) END SRC COMMAND: endTime=2015-07-28 13:43:18.548 requestID=rfFDiTxhxLGL.0 sourceCommandID=0 executionID=0 txID=null modelName=Accounts translatorName=translator-h2 sessionID=rfFDiTxhxLGL principal=user@teiid-security finalRowCount=25 {code} while the following appers only when the server is shut down (notice the time difference between this one and preceding ones): {code:plain} [org.teiid.COMMAND_LOG] (New I/O worker #64) CANCEL USER COMMAND: endTime=2015-07-28 13:43:29.152 requestID=rfFDiTxhxLGL.0 txID=null sessionID=rfFDiTxhxLGL principal=user@teiid-security vdbName=Portfolio vdbVersion=1 finalRowCount=null {code} If there is another command following, the previous command log entry is completed (but it can take even minutes): {code:plain} [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue3) END USER COMMAND: endTime=2015-07-28 14:18:59.511 requestID=q97k+Z4gwV64.0 txID=null sessionID=q97k+Z4gwV64 principal=user@teiid-security vdbName=Portfolio vdbVersion=1 finalRowCount=25 {code} Also the ending log entry of one command and opening entry of another appear in any order. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3595) Add to audit logging the user that logs in and out

by Van Halbert (JIRA)

Van Halbert created TEIID-3595: ---------------------------------- Summary: Add to audit logging the user that logs in and out Key: TEIID-3595 URL: https://issues.jboss.org/browse/TEIID-3595 Project: Teiid Issue Type: Enhancement Components: Server Reporter: Van Halbert Assignee: Steven Hawkins Add the ability to write to the audit log the user that logs in and out. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3594) Change the default for command logging to write User query (start/end)

by Van Halbert (JIRA)

Van Halbert created TEIID-3594: ---------------------------------- Summary: Change the default for command logging to write User query (start/end) Key: TEIID-3594 URL: https://issues.jboss.org/browse/TEIID-3594 Project: Teiid Issue Type: Enhancement Components: Server Reporter: Van Halbert Assignee: Steven Hawkins The command logging currently writes the user query and the source queries. Would like to have multiple levels for command logging, example: - default, log the user query start and end entry - debug, log the use query and the source queries -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3573) Infinispan-dsl-cache translator: Operator <> incorrectly handles NULL values

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-3573?page=com.atlassian.jira.plugin... ] Van Halbert edited comment on TEIID-3573 at 7/28/15 9:13 AM: ------------------------------------------------------------- >> The combination of intNum <> 23 and intNum is Null criteria is an issue in both cases. >I'm not sure what you mean. My thinking was wrong on this, the result is correct, no rows should have been returned. Because, intNum <> 23 removed the rows where intNum = <null>, therefore adding "and intNum is Null" had no intersecting rows to choose from. Based on these tests and to get the right results, both SupportNot and SupportNull need to be set to false. As for performing a full scan for a negated predicate, it appears JDG is not doing a full scan on an indexed attribute. Based on the timing using squirrel, full scan: Total: 3.722, SQL query: 3.719, scan on index: Total: 0.133, SQL query: 0.129 Test query: select intKey,intNum, stringNum, floatnum from smallA where intNum <> 23 And this is only with 49 rows being returned. was (Author: van.halbert): >> The combination of intNum <> 23 and intNum is Null criteria is an issue in both cases. >I'm not sure what you mean. My thinking was wrong on this, the result is correct, no rows should have been returned. Because, intNum <> 23 removed the rows where intNum = <null>, therefore adding "and intNum is Null" had no intersecting rows to choose from. Based on these tests and to get the right results, both SupportNot and SupportNull need to be set to false. As for performing a full scan for a negated predicate, it appears JDG is not doing a full scan on an indexed attribute. Based on the timing using squirrel, full scan: Total: 3.722, SQL query: 3.719, scan on index: Total: 0.133, SQL query: 0.129 And this is only with 49 rows being returned. > Infinispan-dsl-cache translator: Operator <> incorrectly handles NULL values > ---------------------------------------------------------------------------- > > Key: TEIID-3573 > URL: https://issues.jboss.org/browse/TEIID-3573 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.7.1 > Reporter: Filip Elias > Assignee: Van Halbert > > Operator '<>' returns true for NULL <> 1 > Example: > {code} > select intKey,intNum from smallA where intNum<>1 > {code} > It returns also rows which have NULL in column intNum > I believe that NULL <> 1 is not true in SQL. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3573) Infinispan-dsl-cache translator: Operator <> incorrectly handles NULL values

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-3573?page=com.atlassian.jira.plugin... ] Van Halbert commented on TEIID-3573: ------------------------------------ >> The combination of intNum <> 23 and intNum is Null criteria is an issue in both cases. >I'm not sure what you mean. My thinking was wrong on this, the result is correct, no rows should have been returned. Because, intNum <> 23 removed the rows where intNum = <null>, therefore adding "and intNum is Null" had no intersecting rows to choose from. Based on these tests and to get the right results, both SupportNot and SupportNull need to be set to false. As for performing a full scan for a negated predicate, it appears JDG is not doing a full scan on an indexed attribute. Based on the timing using squirrel, full scan: Total: 3.722, SQL query: 3.719, scan on index: Total: 0.133, SQL query: 0.129 And this is only with 49 rows being returned. > Infinispan-dsl-cache translator: Operator <> incorrectly handles NULL values > ---------------------------------------------------------------------------- > > Key: TEIID-3573 > URL: https://issues.jboss.org/browse/TEIID-3573 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.7.1 > Reporter: Filip Elias > Assignee: Van Halbert > > Operator '<>' returns true for NULL <> 1 > Example: > {code} > select intKey,intNum from smallA where intNum<>1 > {code} > It returns also rows which have NULL in column intNum > I believe that NULL <> 1 is not true in SQL. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2884) Support for Amazon Elastic MapReduce

by Kylin Soong (JIRA)

[ https://issues.jboss.org/browse/TEIID-2884?page=com.atlassian.jira.plugin... ] Kylin Soong reassigned TEIID-2884: ---------------------------------- Assignee: Kylin Soong > Support for Amazon Elastic MapReduce > ------------------------------------ > > Key: TEIID-2884 > URL: https://issues.jboss.org/browse/TEIID-2884 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Reporter: Van Halbert > Assignee: Kylin Soong > Fix For: 8.12 > > > Amazon Elastic MapReduce > from http://en.wikipedia.org/wiki/Amazon_Elastic_MapReduce#Amazon_Elastic_MapR... > Elastic MapReduce (EMR)was introduced by Amazon in April 2009. Provisioning of the Hadoop cluster, running and terminating jobs, and handling data transfer between EC2 and S3 are automated by Elastic MapReduce. Apache Hive, which is built on top of Hadoop for providing data warehouse services, is also offered in Elastic MapReduce. > ... > In June 2012, premium options for EMR were added that replace ordinary Hadoop with MapR's M3 and M5 versions. These options provide additional capabilities over and above what the default EMR offering provides. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3573) Infinispan-dsl-cache translator: Operator <> incorrectly handles NULL values

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3573?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3573: --------------------------------------- > The issue with changing SupportNot = False, is that the pushed down criteria is no longer done and end up doing table scans. Yes, that is expected. > The combination of intNum <> 23 and intNum is Null criteria is an issue in both cases. I'm not sure what you mean. > But in the first case where supportNot = TRUE, <null> values are returned in the result set when only specifying intNum <> 23. Since the backend will likely perform a full scan for a negated predicate, there isn't as much overhead as you would expect for turning off support. It would be more work, impose additional capability limitations, and require extension metadata to pursue the fix that was done for ldap (where the predicate is pushed and evaluated in the engine), so I'm ok with the quick fix for now. > Infinispan-dsl-cache translator: Operator <> incorrectly handles NULL values > ---------------------------------------------------------------------------- > > Key: TEIID-3573 > URL: https://issues.jboss.org/browse/TEIID-3573 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.7.1 > Reporter: Filip Elias > Assignee: Van Halbert > > Operator '<>' returns true for NULL <> 1 > Example: > {code} > select intKey,intNum from smallA where intNum<>1 > {code} > It returns also rows which have NULL in column intNum > I believe that NULL <> 1 is not true in SQL. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3593) Add "DBF" translator to file "driver" to support DBF files as 'csv' files

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3593?page=com.atlassian.jira.plugin... ] Steven Hawkins reassigned TEIID-3593: ------------------------------------- Fix Version/s: Open To Community Priority: Minor (was: Major) Description: dBase DBF files are open with MSExcel, LibreOffice etc. and are defined as: http://www.dbf2002.com/dbf-file-format.html It would be good to add support to Teiid as well. was: DBF files open with MSExcel, LibreOffice etc.. I tried to follow the quickstart on Excel files and point to a dbf file instead but it failed... Seems that there is simply a special header to identify the file as DBF and otherwise it opens as any other CSV file. Assignee: (was: Steven Hawkins) Component/s: Misc. Connectors > Add "DBF" translator to file "driver" to support DBF files as 'csv' files > -------------------------------------------------------------------------- > > Key: TEIID-3593 > URL: https://issues.jboss.org/browse/TEIID-3593 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Reporter: Tom Johnston > Priority: Minor > Fix For: Open To Community > > > dBase DBF files are open with MSExcel, LibreOffice etc. and are defined as: > http://www.dbf2002.com/dbf-file-format.html > It would be good to add support to Teiid as well. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3573) Infinispan-dsl-cache translator: Operator <> incorrectly handles NULL values

by Van Halbert (JIRA)

[ https://issues.jboss.org/browse/TEIID-3573?page=com.atlassian.jira.plugin... ] Van Halbert edited comment on TEIID-3573 at 7/27/15 9:22 PM: ------------------------------------------------------------- Kept IsNull = false, changed supportNot = FALSE Query: select intKey,intNum from smallA where intNum <> 23 * teiid doesn't push down criteria and doesn't include the <null> value rows Query (adding Is Null): select intKey,intNum from smalla where intNum <> 23 and intNum is Null * no criteria pushed down, and returned no rows Query (adding Is Not Null): select intKey,intNum from smalla where intNum <> 23 and intNum is Not Null - nothing pushed down: teiid handles WHERE g_0.intNum <> 23 and the Not Null check, the results do not have the <null> values Query: select intKey,intNum, stringNum, floatnum from smalla where intNum Is Null * no criteria pushed down, and returns on the 4 rows that have <null> value Query: select intKey,intNum, stringNum, floatnum from smalla where intNum Is Not Null * returned the correct results was (Author: van.halbert): Kept IsNull = false, changed supportNot = FALSE Query: select intKey,intNum from smallA where intNum <> 23 * teiid doesn't push down criteria and doesn't include the <null> value rows Query (adding Is Null): select intKey,intNum from smalla where intNum <> 23 and intNum is Null * no criteria pushed down, and returned no rows Query: select intKey,intNum, stringNum, floatnum from smalla where intNum Is Null * no criteria pushed down, and returns on the 4 rows that have <null> value Query: select intKey,intNum, stringNum, floatnum from smalla where intNum Is Not Null * returned the correct results > Infinispan-dsl-cache translator: Operator <> incorrectly handles NULL values > ---------------------------------------------------------------------------- > > Key: TEIID-3573 > URL: https://issues.jboss.org/browse/TEIID-3573 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Affects Versions: 8.7.1 > Reporter: Filip Elias > Assignee: Van Halbert > > Operator '<>' returns true for NULL <> 1 > Example: > {code} > select intKey,intNum from smallA where intNum<>1 > {code} > It returns also rows which have NULL in column intNum > I believe that NULL <> 1 is not true in SQL. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues July 2015