[
https://issues.apache.org/jira/browse/OPENJPA-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18111579#comment-18111579
]
ASF subversion and git services commented on OPENJPA-2956:
----------------------------------------------------------
Commit b31dd36eabf446c32c71473941579bad12b72037 in openjpa's branch
refs/heads/master from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=b31dd36ea ]
[OPENJPA-2956] Cover the in-memory null precedence and set operation rejection
Review feedback. Both cases run through the in-memory executor by supplying
a candidate collection, and both fail against the unchanged kernel: the null
precedence test because the comparator ignored NULLS FIRST/LAST, the set
operation test because the query failed with a NullPointerException instead
of saying it cannot be evaluated in memory.
ID() is deliberately not covered. It cannot be reached from JPQL in memory
at all: JPQLExpressionBuilder casts the value from getThis() to Path, the
in-memory factory returns a Val, and the query dies with a
ClassCastException before the identity is evaluated. That is an older,
separate defect; a test for ID() has to wait for it.
> In-memory ID(), set ops and nullPrecedence unimplemented
> --------------------------------------------------------
>
> Key: OPENJPA-2956
> URL: https://issues.apache.org/jira/browse/OPENJPA-2956
> Project: OpenJPA
> Issue Type: Sub-task
> Components: jpa
> Affects Versions: 4.2.0
> Reporter: Maxim Solodovnik
> Priority: Major
> Fix For: 4.2.0
>
>
> Discussion thread:
> https://github.com/apache/openjpa/pull/144#discussion_r3683000248
> **(medium)** `getNativeObjectId` returns the same `GetObjectId` as
> `getObjectId`, which evaluates to the internal ObjectId wrapper (e.g.
> LongId), not the raw PK value - so an in-memory `ID(e) = :id` comparison
> against the plain key may never match; should it unwrap like the JDBC side?
> Similarly `setOperands`/`setOperationType` and `nullPrecedence` appear
> consumed only by the JDBC store, so in-memory execution of
> UNION/INTERSECT/EXCEPT or NULLS FIRST/LAST silently produces wrong results -
> should the in-memory path reject or implement them?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
