[
https://issues.apache.org/jira/browse/IGNITE-28374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18083272#comment-18083272
]
Evgeny Stanilovsky edited comment on IGNITE-28374 at 5/25/26 10:52 AM:
-----------------------------------------------------------------------
[[email protected]] first of all @Ignore defined test:
SelectByKeyFieldTest#testCompositePkWithPersonCompositeKeyAndDifferentCmpOperations(false)
will fail here:
_key8.deserialize()
second: I miss the goal of such a tests\functionslity, i look into
testCompositePkWithPersonCompositeKeyAndDifferentCmpOperations(*true*)
and found that query:
{noformat}
assertQuery("select id, name, age, _key from PUBLIC.PERSON where _key >=
?").withParams(BinaryObject(id=8, name=foo8))
{noformat}
will return resultSet like:
{noformat}
id=5, name=foo5
id=6, name=foo6
id=7, name=foo7
id=8, name=foo8
{noformat}
I vonder: is it really expected\can be used in real queries\described (how non
comparable objects are compared) thus anuone can have a deterministic results
after ?
was (Author: zstan):
[[email protected]] first of all @Ignore defined test:
SelectByKeyFieldTest#testCompositePkWithPersonCompositeKeyAndDifferentCmpOperations(false)
will fail here:
_key8.deserialize()
second: I miss the goal of such a tests\functionslity, i look into
testCompositePkWithPersonCompositeKeyAndDifferentCmpOperations(*true*)
and found that query:
"select id, name, age, _key from PUBLIC.PERSON where _key >=
?".withParams(BinaryObject(id=8, name=foo8))
will return resultSet like:
{noformat}
id=5, name=foo5
id=6, name=foo6
id=7, name=foo7
id=8, name=foo8
{noformat}
I vonder: is it really expected\can be used in real queries\described (how non
comparable objects are compared) thus anuone can have a deterministic results
after ?
> 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)
