January 2012 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-1801) Async Event Processing: Reset and Re-run plan

by Mark Addleman (Created) (JIRA)

Async Event Processing: Reset and Re-run plan ---------------------------------------------- Key: TEIID-1801 URL: https://issues.jboss.org/browse/TEIID-1801 Project: Teiid Issue Type: Feature Request Reporter: Mark Addleman Assignee: Steven Hawkins In order to processing a stream of events aggregated within a specified time window, the engine should provide some way of specifying the time period (analogous to a window), reset and re-rerun the plan for every time period. There should also be an engine to translator callback indicating that the plan has been reset as opposed to closed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

8
10
0 / 0

[JBoss JIRA] (TEIID-1852) Salesforce Translator doesnt handle Time types

by Mark Drilling (Created) (JIRA)

Salesforce Translator doesnt handle Time types ---------------------------------------------- Key: TEIID-1852 URL: https://issues.jboss.org/browse/TEIID-1852 Project: Teiid Issue Type: Bug Components: Salesforce Connector Affects Versions: 7.6 Reporter: Mark Drilling Assignee: Steven Hawkins Attachments: SFTestVDB.vdb Query the BusinessHours table imported from Salesforce, which contains columns with 'time' datatype. For example, the query: SELECT Name,CreatedDate,MondayStartTime FROM SFTest.salesforce.BusinessHours Results in: Error Code:ERR.003.029.0025 Message:Failed to transform String to Time. Expected format = hh:mm:ss for 08:00:00.000Z It looks like the code in QueryExecutionImpl.getCellDatum needs to handle translation of the salesforce time format -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

6
7
0 / 0

[JBoss JIRA] Created: (TEIID-1326) API request: rewrite query/command before it reaches the teiid planner

by Mark Addleman (JIRA)

API request: rewrite query/command before it reaches the teiid planner ----------------------------------------------------------------------- Key: TEIID-1326 URL: https://jira.jboss.org/browse/TEIID-1326 Project: Teiid Issue Type: Feature Request Components: Query Engine Affects Versions: 7.1 Reporter: Mark Addleman Assignee: Steven Hawkins I'd like an API to inspect and rewrite a user query/command before it reaches the Teiid planner. The use case is to rewrite the query/command to implement view-like capabilities. For example: SELECT a,b,c FROM table1 AS t WHERE t.a='xyz' would be rewritten as: SELECT a,b,c FROM (SELECT a,b,c FROM table2 UNION SELECT a,b,c FROM table3) AS t I imagine this API would be similar to the translator API: it would receive a data structure representing the query/command and use a visitor to rewrite the query. As a convenience, it would be nice to have something similar to the SQLConversionVisitor. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

6
19
0 / 0

[JBoss JIRA] (TEIID-1869) Simple capabilities with PostgreSQL 8.3 using decodeinteger causes comm failure

by Paul Nittel (Created) (JIRA)

Simple capabilities with PostgreSQL 8.3 using decodeinteger causes comm failure ------------------------------------------------------------------------------- Key: TEIID-1869 URL: https://issues.jboss.org/browse/TEIID-1869 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 7.6 Reporter: Paul Nittel Assignee: Steven Hawkins We use PostgreSQL 8.3 twice: once to test push-down to the source and the other to test not-pushed-down queries. The following works fine with the push-down. It's not so good when we use simple-capabilities. The query is: SELECT IntKey, BooleanValue, DECODEINTEGER(BooleanValue, 'false,3,true,7') AS Decoded FROM BQT1.SmallA ORDER BY IntKey What happens is: $ ./RunQT jdbc:teiid:QT_PostgreSQL83@mm://localhost:31000 user user yes "SELECT IntKey, BooleanValue, DECODEINTEGER(BooleanValue, 'false,3,true,7') AS Decoded FROM BQT1.SmallA ORDER BY IntKey" Caught SQLException: [SingleInstanceCommunicationException] 1 [EOFException] In the case of query testing, all subsequent queries fail due to a closed socket error. Dev indicated "That's a bug with the rewriter. We are just converting the decode function into a searched case statement, but are leaving the then values as string - rather than converting them to integers. The pushdown works because the resulting string value is converted to an integer via the translator/driver logic." -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

5
5
0 / 0

[JBoss JIRA] (TEIID-1902) Update extension metadata property keys

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-1902: ------------------------------------- Summary: Update extension metadata property keys Key: TEIID-1902 URL: https://issues.jboss.org/browse/TEIID-1902 Project: Teiid Issue Type: Task Components: Misc. Connectors, Query Engine Affects Versions: 7.6.1 Reporter: Steven Hawkins Assignee: Steven Hawkins Priority: Critical As per a discussion with designer folks we will now index extension property keys that are more fool-proof in Clark notation: {nsURI}key Any reference to an extension property key will need to be updated with the proper uri. For the time being any lookup that was using a valid old key will use both the old and the new form for backwards compatibility. Also the use of an extension property in the ldap translator should be changed to use the standard format metadata property. We should also touch on property keys in our developer's guide. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
3
0 / 0

[JBoss JIRA] Created: (TEIID-1720) Support for JBoss AS 7.x as host environment

by Ramesh Reddy (JIRA)

Support for JBoss AS 7.x as host environment -------------------------------------------- Key: TEIID-1720 URL: https://issues.jboss.org/browse/TEIID-1720 Project: Teiid Issue Type: Feature Request Components: Server Affects Versions: 7.6 Reporter: Ramesh Reddy Assignee: Ramesh Reddy Fix For: 8.0 Currently Teiid 7.x line is based on JBoss AS 5.1.0. Migrate host environment to JBoss AS 7.x. This JIRA will be used to put in some initial work, then will be used bucket to add sub-tasks involved in the overhaul. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

4
5
0 / 0

[JBoss JIRA] (TEIID-1841) week function in teiid not returning expected value

by Graeme Gillies (Created) (JIRA)

week function in teiid not returning expected value --------------------------------------------------- Key: TEIID-1841 URL: https://issues.jboss.org/browse/TEIID-1841 Project: Teiid Issue Type: Bug Affects Versions: 7.5 Environment: Teiid 7.5 running on java 1.6 openjdk on rhel5 Reporter: Graeme Gillies Assignee: Steven Hawkins One of our users of our teiid instance as reported that the week function (to determine which week of the year it is) operates in teiid a little different to how they expect. Teiid resets the week count to 1 on every 1st of January even though the day is not the 1st day of the week (Sunday in here). But Postgres will only resets the week count to 1 only on the 1st Monday of the year. The examples below compare the results return by teiid and Postgres: {noformat} # Teiid result: EngVDBR=> select week(parsedate('2011-01-01', 'yyyy-MM-dd')) AS Week; week ------ 1 (1 row) EngVDBR=> select week(parsedate('2011-01-02', 'yyyy-MM-dd')) AS Week; week ------ 2 (1 row) {noformat} {noformat} # Postgres result: postgres=> SELECT EXTRACT(WEEK FROM DATE '2011-01-01') AS Week; week ------ 52 (1 row) postgres=> SELECT EXTRACT(WEEK FROM DATE '2011-01-03') AS Week; week ------ 1 (1 row) {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

4
4
0 / 0

[JBoss JIRA] Created: (TEIID-1604) Rationalize the context objects

by Steven Hawkins (JIRA)

Rationalize the context objects ------------------------------- Key: TEIID-1604 URL: https://issues.jboss.org/browse/TEIID-1604 Project: Teiid Issue Type: Quality Risk Components: Connector API, Query Engine Affects Versions: 8.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 8.0 The the CommandContext and the ExecutionContext should have their methods rationalized so that there is a uniform way to access information (ExecutionContext.getCommandContext().getSession().getUsername() vs. ExecutionContext.getUserName()) and/or at least ensure that method names are the same. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

2
2
0 / 0

[JBoss JIRA] (TEIID-1903) count() function with salesforce adaptor not behaving correctly

by Graeme Gillies (JIRA)

Graeme Gillies created TEIID-1903: ------------------------------------- Summary: count() function with salesforce adaptor not behaving correctly Key: TEIID-1903 URL: https://issues.jboss.org/browse/TEIID-1903 Project: Teiid Issue Type: Bug Components: Salesforce Connector Affects Versions: 7.5 Environment: java version "1.6.0_20" OpenJDK Runtime Environment (IcedTea6 1.9.10) (rhel-1.23.1.9.10.el5_7-x86_64) OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode) on Red Hat Enterprise Linux Server release 5.7 (Tikanga) Reporter: Graeme Gillies Assignee: Steven Hawkins Hi, I noticed the following strange behaviour with the salesforce connector. In the below example, Bugzilla is normal JDBC datasource to a mysqldb, while SFDC is a salesforce.com datasource {noformat} EngVDBR=> select count(*) from Bugzilla.bugs; count -------- 604680 (1 row) EngVDBR=> select count(*) from SFDC.salesforce.Case_; count -------- 455487 (1 row) EngVDBR=> select count(1) from SFDC.salesforce.Case_; ERROR: SalesforceAPI: The number of result rows has exceeded the maximum result rows "100,000" DETAIL: org.teiid.jdbc.TeiidSQLException: SalesforceAPI: The number of result rows has exceeded the maximum result rows "100,000" EngVDBR=> select count(1) from Bugzilla.bugs; count -------- 604680 (1 row) EngVDBR=> {noformat} I would have expected count(1) on salesforce to work the same as count(*), but it returns the maxrows error even though it should only return one row. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

2
5
0 / 0

[JBoss JIRA] (TEIID-1889) Standardize logging in Teiid

by Ramesh Reddy (Created) (JIRA)

Standardize logging in Teiid ---------------------------- Key: TEIID-1889 URL: https://issues.jboss.org/browse/TEIID-1889 Project: Teiid Issue Type: Task Reporter: Ramesh Reddy Assignee: Steven Hawkins Per http://community.jboss.org/wiki/HowToLogInJBossProjects rework the logging to include the id for all the messages > INFO -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

6
7
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues January 2012