[JBoss JIRA] Created: (TEIID-806) JDBC connector handling of convert is inconsistent
by Steven Hawkins (JIRA)
JDBC connector handling of convert is inconsistent
--------------------------------------------------
Key: TEIID-806
URL: https://jira.jboss.org/jira/browse/TEIID-806
Project: Teiid
Issue Type: Quality Risk
Components: JDBC Connector
Affects Versions: 6.0.0
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 6.3.0
If a source lacks the exact representation of a Teiid type we approximate it with the closest source type. Pushed converts will typically not have the same affect as if they are evaluated in the engine. For example sources lacking byte or tinyint types are having conversions dropped rather, but the actual effect should be modulo the max byte value. We also are not ensuring that the truncation or rounding behavior is the same for all conversions - such as from a floating point number to a fixed point.
--
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
13 years, 10 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
13 years, 10 months
[JBoss JIRA] Created: (TEIID-739) JDBC Connector updates
by Steven Hawkins (JIRA)
JDBC Connector updates
----------------------
Key: TEIID-739
URL: https://jira.jboss.org/jira/browse/TEIID-739
Project: Teiid
Issue Type: Feature Request
Components: JDBC Connector
Affects Versions: 6.2.0
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 6.2.0
The PostgreSQL translator should assume the use of a 8.0 jdbc client (supports back to the 7.2 server) so that we can remove DatePartFunctionModifer/ModifiedDatePartFunctionModifer also support for the bit functions should be added.
The SQL Server translator / capabilities should be updated to assume the use of a 2005, DataDirect, or later driver (all support back to sql server 2000) so that support for most of the time functions can be added.
--
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
13 years, 10 months
[JBoss JIRA] Created: (TEIID-741) SQL Server type hadling issues
by Steven Hawkins (JIRA)
SQL Server type hadling issues
------------------------------
Key: TEIID-741
URL: https://jira.jboss.org/jira/browse/TEIID-741
Project: Teiid
Issue Type: Bug
Components: JDBC Connector
Affects Versions: 6.0.0
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 6.2.0
If we pushdown a convert(stringvalue, char) function, it turns into the source expression convert(char, stringvalue), which has the following problems: it defaults to type char(30) which is right padded, it is not trimmed since the target type was Char and the trim logic looks only for String. Also it does not account for empty string mapping to null.
The SQL Server tinyint type is unsigned. Our import needs to be modified to this to short, since our byte type is unsigned. Pushing down a convert(numericvalue, byte) as convert(tinyint, numericvalue) is problematic if the byte values are stored in a signed manner.
--
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
13 years, 10 months