[
https://issues.apache.org/jira/browse/IGNITE-28374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-28374:
-------------------------------------
Description:
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.
was:
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.
> 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
>
> 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)
