[JBoss JIRA] Created: (TEIID-902) Restructure planning
by Steven Hawkins (JIRA)
Restructure planning
--------------------
Key: TEIID-902
URL: https://jira.jboss.org/jira/browse/TEIID-902
Project: Teiid
Issue Type: Task
Components: Query Engine
Affects Versions: 7.0
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 7.0
All transformation queries should be cached - not just views.
All cached queries should already be validated - and not revalidated with every request.
Cached queries should be stored individually - not as full and separate trees as they are now, where the same view command exists can exist multiple times in cache.
The choice about whether to use a materialized view or not should also be moved to planning time - not a resolver activity.
We should remove the concept of non-embedded command from everything except planning logic. It's error-prone and confusing in a resolving/rewrite context.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 7 months
[JBoss JIRA] Created: (TEIID-894) Query inexplicably failing Query Testing only with MySQL
by Paul Nittel (JIRA)
Query inexplicably failing Query Testing only with MySQL
--------------------------------------------------------
Key: TEIID-894
URL: https://jira.jboss.org/jira/browse/TEIID-894
Project: Teiid
Issue Type: Bug
Components: Query Engine
Affects Versions: 7.0
Environment: Fedora 10, Teiid 7.0.0 M1
Reporter: Paul Nittel
Assignee: Steven Hawkins
Series 9000, #7 fails with MySql and passes with all the other sources.
Original Query
SELECT BQT1.SmallA.IntKey, BQT2.SmallB.FloatNum FROM BQT1.SmallA, BQT2.SmallB WHERE BQT1.SmallA.IntKey = BQT2.SmallB.FloatNum AND BQT1.SmallA.IntKey >= 0 AND BQT2.SmallB.IntKey >= 0 ORDER BY BQT1.SmallA.IntKey;
It's supposed to return 25 rows, but returns 0. Let's ignore the "ORDER BY" since it just adds to the code (and doesn't factor into the issue since it works the same with or without).
If I remove the "AND BQT2.SmallB.IntKey >= 0", it works! I get 25 rows.
SELECT BQT1.SmallA.IntKey, BQT2.SmallB.FloatNum FROM BQT1.SmallA, BQT2.SmallB WHERE BQT1.SmallA.IntKey = BQT2.SmallB.FloatNum AND BQT1.SmallA.IntKey >= 0;
If I switch it so the first condition is removed and the second remains, it FAILS
SELECT BQT1.SmallA.IntKey, BQT2.SmallB.FloatNum FROM BQT1.SmallA, BQT2.SmallB WHERE BQT1.SmallA.IntKey = BQT2.SmallB.FloatNum AND BQT2.SmallB.IntKey >= 0;
What doesn't it like about "BQT2.SmallB >= 0" ?? I ran this query--and the one with only "BQT1.SmallA >= 0"--with OPTION DEBUG.
Stuff is attached.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 7 months
[JBoss JIRA] Created: (TEIID-754) LOCATE() function isn't being translated correctly by Oracle Connector
by Larry O'Leary (JIRA)
LOCATE() function isn't being translated correctly by Oracle Connector
----------------------------------------------------------------------
Key: TEIID-754
URL: https://jira.jboss.org/jira/browse/TEIID-754
Project: Teiid
Issue Type: Bug
Components: JDBC Connector
Affects Versions: 6.1.0, 6.0.0, 6.2.0
Reporter: Larry O'Leary
Assignee: Larry O'Leary
Fix For: 6.2.0
The rewritten/translated query for the MMx LOCATE() function to Oracle's instr() function does not appear to be correct.
SELECT locate(INTNUM, '234567890', 1) FROM SMALLA WHERE INTKEY = 26
Is being rewritten for Oracle as:
SELECT instr('234567890', to_char(SmallA.IntNum), 2) FROM SmallA WHERE SmallA.IntKey = 26
In this case Oracle will return 0 for instr() because Oracle starts at position 1.
The query should be:
SELECT instr('234567890', to_char(SmallA.IntNum), 1) FROM SmallA WHERE SmallA.IntKey = 26
Furthermore, if I pass a negative value to LOCATE() it appears we assume position 1. If the negative value is sent to Oracle, Oracle goes from the end of the string. We should prevent this (if not already).
In 5.5.1 the rewritten query is even different and may ore may not be correct. I have not checked 5.5.3/5.5.4 and/or Westport/Teiid.
Here are the test cases that should cover this issue:
public void testRewriteLocate() throws Exception {
String input = "SELECT locate(INTNUM, 'chimp', 1) FROM SMALLA"; //$NON-NLS-1$
String output = "SELECT instr('chimp', to_char(SmallA.IntNum), 1) FROM SmallA"; //$NON-NLS-1$
helpTestVisitor(getTestVDBPath(),
input,
new Integer(TranslatedCommand.EXEC_TYPE_QUERY),
output);
}
public void testRewriteLocate2() throws Exception {
String input = "SELECT locate(STRINGNUM, 'chimp') FROM SMALLA"; //$NON-NLS-1$
String output = "SELECT instr('chimp', SmallA.StringNum) FROM SmallA"; //$NON-NLS-1$
helpTestVisitor(getTestVDBPath(),
input,
new Integer(TranslatedCommand.EXEC_TYPE_QUERY),
output);
}
public void testRewriteLocate3() throws Exception {
String input = "SELECT locate(INTNUM, '234567890', 1) FROM SMALLA WHERE INTKEY = 26"; //$NON-NLS-1$
String output = "SELECT instr('234567890', to_char(SmallA.IntNum), 1) FROM SmallA WHERE SmallA.IntKey = 26"; //$NON-NLS-1$
helpTestVisitor(getTestVDBPath(),
input,
new Integer(TranslatedCommand.EXEC_TYPE_QUERY),
output);
}
public void testRewriteLocate4() throws Exception {
String input = "SELECT locate('c', 'chimp', 1) FROM SMALLA"; //$NON-NLS-1$
String output = "SELECT 1 FROM SmallA"; //$NON-NLS-1$
helpTestVisitor(getTestVDBPath(),
input,
new Integer(TranslatedCommand.EXEC_TYPE_QUERY),
output);
}
public void testRewriteLocate5() throws Exception {
String input = "SELECT locate(STRINGNUM, 'chimp', -5) FROM SMALLA"; //$NON-NLS-1$
String output = "SELECT instr('chimp', SmallA.StringNum, 1) FROM SmallA"; //$NON-NLS-1$
helpTestVisitor(getTestVDBPath(),
input,
new Integer(TranslatedCommand.EXEC_TYPE_QUERY),
output);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 7 months