[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/…
[View More]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
[View Less]
12 years, 10 months
[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 …
[View More]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
[View Less]
12 years, 10 months
[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 …
[View More]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
[View Less]
12 years, 10 months
[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 …
[View More]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
[View Less]
12 years, 10 months
[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-…
[View More]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
[View Less]
12 years, 10 months