[
https://issues.apache.org/jira/browse/PHOENIX-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ayden Bissessar updated PHOENIX-4991:
-------------------------------------
Summary: Query fails when mixing different types of IN operators (was:
Query fails when mixing different types of IN clauses)
> Query fails when mixing different types of IN operators
> -------------------------------------------------------
>
> Key: PHOENIX-4991
> URL: https://issues.apache.org/jira/browse/PHOENIX-4991
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.13.1
> Reporter: Ayden Bissessar
> Priority: Minor
>
> When mixing different types of IN clauses in a query, we get a failure of:
> {code:java}
> java.sql.SQLException: ERROR 201 (22000): Illegal data. Expected length of at
> least 8 bytes, but had 2
> {code}
> From my experience, you see this error when Phoenix cannot decode the hex
> values stored in HBase, typically caused when you have inserted data outside
> of Phoenix. However, why would we see this same error when different
> implementations of the query return the results fine?
> E.g.
> {code:java}
> # Query 1 - WORKS: One column per IN clause only
> "id1" in (1234,5678) and "id2" in (8642,2468) and "id3" IN (1,2,3);
> VS
> # Query 2 - WORKS: Combined column IN clause only
> ("id1","id2","id3") IN ((1234,8642,,1),(5678,2468,1));
> VS
> # Query 3 - FAILS: Combined column method AND one column method
> ("id1","id2") IN ((1234,8642),(5678,2468)) AND "id3" IN (1,2,3);
> {code}
> My guess would be query 3 isn't officially supported, but would like some
> more information. Why would changing this cause an illegal amount of bytes to
> be returned?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)