[
https://issues.apache.org/jira/browse/IGNITE-28374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18083395#comment-18083395
]
Kirill Tkalenko commented on IGNITE-28374:
------------------------------------------
[~zstan] You may not have noticed, but I then tried to answer the question
assuming that I understood the query.
> If omit this fact, then it checks that if you perform queries with predicates
> other than equality, they must be executed correctly according to the
> comparison of binary objects.
I'll try to give more details.
In ticket [IGNITE-28331|https://issues.apache.org/jira/browse/IGNITE-28331], I
fixed the main issue with searching by the composite "_key" so that the search
is performed by the primary index of a single value rather than a full scan of
the primary index. By the way, you left comments there. As part of this ticket,
after communicating with the reviewer, I also fixed the behavior of logical
operators other than equality ("="), such as >/>=/</<=/!=.
In the test you provided, I'm checking that the binary operators >/>=/</<=/!=
work as expected and predictably for "_key."
> Fix SQL select by _key for a composite pk for key class in Calcite engine
> -------------------------------------------------------------------------
>
> Key: IGNITE-28374
> URL: https://issues.apache.org/jira/browse/IGNITE-28374
> Project: Ignite
> Issue Type: Bug
> Reporter: Kirill Tkalenko
> Assignee: Kirill Tkalenko
> Priority: Major
> Labels: ignite-2, ise
>
> IGNITE-28331 successfully fixed selects with "_KEY" for composite primary
> key, but it still doesn't resolve the issue when the key class is passed as a
> parameter.
> See todo and issue needs to be fixed in this ticket.
> Research result:
> If convert a POJO to a BinaryObject for the index search boundary, then after
> retrieving rows from the index, the Calcite filter from the query is applied
> within the iterator, comparing the key retrieved from the index with the
> argument passed to the query. This results in a comparison of the
> BinaryObject with the POJO, which cannot be equal, and therefore such rows
> are skipped.
> See
> *org.apache.ignite.internal.processors.query.calcite.exec.rel.ScanTableRowNode#processNextRow*.
> This problem can be fixed, for example, by converting a POJO to a
> BinaryObject when receiving them as a query argument in method
> *org.apache.ignite.internal.processors.query.calcite.exec.ExecutionContext#getParameter*.
> However, this could break the ability to pass POJO to user-defined
> functions. Perhaps there is a simpler or more elegant solution.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
