[JBoss JIRA] (TEIID-1465) Join between char and varchar
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-1465?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-1465.
---------------------------------
> Join between char and varchar
> -----------------------------
>
> Key: TEIID-1465
> URL: https://issues.jboss.org/browse/TEIID-1465
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 7.3
> Environment: Teiid 7.3 deployed on Jboss AS 5.1.0 GA running on Ubuntu Server 10.04 LTS, MySQL 5.1.51 running on the same machine as JBoss, SQL Server 2000 Standard SP4 running on Windows Server 2003
> Reporter: Claudio Venturini
> Assignee: Steven Hawkins
> Labels: char, join, varchar
> Fix For: 7.7, 8.0
>
>
> Joins between char and varchar fields fail.
> Suppose to have a table T1 with a field A, declared as char(10), and a table T2 with a field B, declared as varchar(10). Suppose that the two tables have the following data.
> *T1*:
> ||A||
> |ML0001|
> *T2*:
> ||B||
> |ML0001|
> When performing a INNER JOIN with the condition {{T1.A = T2.B}} the result set is empty, even if the two record match correctly.
> This happens when the two base tables refer to two different sources, because if they are in the same source Teiid pushes the join to the source, which computes it correctly.
> I think the problem is in the comparison of the two strings. I have the table T1 in SQL Server 2000, and the table T2 in MySQL 5.1.
> If one asks SQL Server to convert the string to bytes, the result is {{0x4D4C3030303120202020}}, because the string is filled with (invisible) blanks in order to reach the limit of 10 characters. Note that if one asks for the length of that string, SQL Server states (correctly) that it is 6 characters.
> The string in MySQL is a VARCHAR(10), so its conversion to binary is {{0x4D4C30303031}}.
> I think that Teiid compares the two binary strings in their entire length. That comparison fails, and no match is found.
> The problem remains even if the table T1 is placed in MySQL, and T2 in SQL Server (the opposite situation). I also verified that the problem exists either when querying the source models or view models built over them.
> *Workaround:*
> A workaround exists but it is too complex (IMHO). I haven't tested it with many records, but I think it will slow down performances considerably.
> It consists in casting the string from char to varchar, and then trimming it (with RTRIM() and LTRIM() because SQL Server doesn't support TRIM()). So the join condition is:
> {noformat}
> RTRIM(LTRIM(CAST(T1.A AS VARCHAR))) = T2.B
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (TEIID-2837) Cassandra: doesn't work with Case Sensitvie KEYSPACE and TABLE name
by Ivan Chan (JIRA)
[ https://issues.jboss.org/browse/TEIID-2837?page=com.atlassian.jira.plugin... ]
Ivan Chan commented on TEIID-2837:
----------------------------------
Sure. Thanks for looking.
https://issues.jboss.org/browse/TEIID-2932
> Cassandra: doesn't work with Case Sensitvie KEYSPACE and TABLE name
> --------------------------------------------------------------------
>
> Key: TEIID-2837
> URL: https://issues.jboss.org/browse/TEIID-2837
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.6
> Environment: Cassandra with Teiid 8.6
> Reporter: Ivan Chan
> Assignee: Steven Hawkins
> Labels: teiid
> Fix For: 8.7
>
>
> Teiid doesn't work with KeySpace or Table which contains UpperCase.
> Reference From Cassandra - Using double quote for Case Sensitive KeySpace and Table:
> http://www.datastax.com/docs/1.1/references/cql/CREATE_KEYSPACE
> Exception when try to deploy:
> java.lang.NullPointerException
> at org.teiid.translator.cassandra.metadata.CassandraMetadataProcessor.processMetadata(CassandraMetadataProcessor.java:52)
> at org.teiid.translator.cassandra.CassandraExecutionFactory.getMetadata(CassandraExecutionFactory.java:100)
> at org.teiid.translator.cassandra.CassandraExecutionFactory.getMetadata(CassandraExecutionFactory.java:53)
> at org.teiid.query.metadata.NativeMetadataRepository.loadMetadata(NativeMetadataRepository.java:61)
> at org.teiid.query.metadata.ChainingMetadataRepository.loadMetadata(ChainingMetadataRepository.java:55)
> at org.teiid.runtime.EmbeddedServer.loadMetadata(EmbeddedServer.java:644)
> at org.teiid.runtime.AbstractVDBDeployer.loadMetadata(AbstractVDBDeployer.java:161)
> at org.teiid.runtime.EmbeddedServer.deployVDB(EmbeddedServer.java:605)
> at org.teiid.runtime.EmbeddedServer.deployVDB(EmbeddedServer.java:536)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months
[JBoss JIRA] (TEIID-2439) jdbc socket transport support in teiid embedded mode
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2439?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-2439.
---------------------------------
> jdbc socket transport support in teiid embedded mode
> ----------------------------------------------------
>
> Key: TEIID-2439
> URL: https://issues.jboss.org/browse/TEIID-2439
> Project: Teiid
> Issue Type: Feature Request
> Components: Embedded
> Reporter: Himanshu Kapoor
> Assignee: Ramesh Reddy
> Fix For: 8.6
>
>
> As a teiid embedded user there must be JDBC socket transport in embedded mode so that external java application (outside the application server in which teiid embedded has been hosted) can connect to the vdb's using the teiid jdbc driver and can perform operation on it.
> This feature will really help the teiid embedded users to start using this feature in enterprises level applications .
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 8 months