[
https://issues.apache.org/jira/browse/IGNITE-28374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18083302#comment-18083302
]
Kirill Tkalenko commented on IGNITE-28374:
------------------------------------------
[~zstan] Hello.
First of all, 2 tests are ignored.
Let's look at the questions:
1. _key8.deserialize():
My mistake, it is necessary to replace make a replacement on line 308 with
```
sql("create table PUBLIC.PERSON(id int, name varchar, surname varchar, age int,
primary key(id, name))");
// -->
sql(String.format(
"create table PUBLIC.PERSON(id int, name varchar, surname varchar, age int,
primary key(id, name)) with \"key_type=%s\"",
PersonCompositeKey.class.getName()
));
```
and then the test will just start to fall due to an incorrect result.
2. about the goal of
testCompositePkWithPersonCompositeKeyAndDifferentCmpOperations({*}true{*}):
As you indicated, there is no query there.
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.
> 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)
