[
https://issues.apache.org/jira/browse/OPENJPA-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18110831#comment-18110831
]
ASF subversion and git services commented on OPENJPA-2956:
----------------------------------------------------------
Commit 6dcf26af7a353c6f156c711974bf5bdd48faf8dd in openjpa's branch
refs/heads/OPENJPA-2956 from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=6dcf26af7 ]
[OPENJPA-2956] Unwrap ID(), honour null precedence and reject set operations in
memory
Three separate defects on the in-memory path, all reachable: the executor
is selected whenever a candidate collection is supplied, when the store
does not support datastore execution, or when dirty instances are queried
with FlushBeforeQueries disabled.
ID() returned the internal identity wrapper rather than the raw key, so a
comparison against the plain key threw a ClassCastException out of
Filters.convert for numeric ids, never matched for an @EmbeddedId, and
matched only by accident for a String id. It now unwraps exactly as the
JDBC projection does. The wrapper-returning getObjectId() is unchanged.
NULLS FIRST and NULLS LAST were ignored: the comparator hard coded nulls
last when ascending and first when descending, so two of the four
combinations were right by chance and two were silently wrong. The
requested precedence is now threaded through, falling back to the previous
policy when none is given.
Set operations produced a NullPointerException from a compound expression
with no filter, or an empty result. They are now rejected with a message
that says why the query is running in memory and how to avoid it: the
executor is built for one candidate extent and has no multiset semantics,
and a candidate collection has no defined meaning across operands.
Note that the in-memory path cannot yet be exercised end to end from JPQL
with an identification variable: JPQLExpressionBuilder casts the value from
getThis() to Path, and the in-memory factory returns a Val, so it fails with
a ClassCastException. That is an older, separate defect and wants its own
issue.
> 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)
