[
https://issues.jboss.org/browse/TEIID-1966?page=com.atlassian.jira.plugin...
]
Steven Hawkins commented on TEIID-1966:
---------------------------------------
Can you provide more context for this? I can't reproduce that behavior. If the user
is written as an OR such as the above, then the rewriter will change it into an IN
predicate. That would happen before pushdown.
Regardless, the full solution seems to be that if a translator doesn't support IN, but
does support =/OR, then we still should push these situations as expanded ORs.
supportsInCriteria is ignored
-----------------------------
Key: TEIID-1966
URL:
https://issues.jboss.org/browse/TEIID-1966
Project: Teiid
Issue Type: Bug
Affects Versions: 7.7.1
Environment: Win7
Reporter: Michal Navrkal
Assignee: Steven Hawkins
SQL query whose WHERE clause contains ORed conditions is sent down to custom translator
as IN clause even when the custom translator doesn' support IN clause.
public class EWSExecutionFactory extends
ExecutionFactory<ConnectionFactory, EWSConnection> {
...
@Override
public boolean supportsInCriteria()
{
return false;
}
@Override
public boolean supportsInCriteriaSubquery()
{
return false;
}
}
SELECT COUNT(*) FROM Storage.MVDETAIL WHERE Storage.MVDETAIL.CUA = '2D03' OR
Storage.MVDETAIL.CUA = '2D07'
is translated to
SELECT COUNT(*) FROM Storage.MVDETAIL WHERE Storage.MVDETAIL.CUA IN ('2D03',
'2D07')
--
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