You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Maxim Solodovnik (Jira)" <ji...@apache.org> on 2026/09/05 08:19:00 UTC

[jira] [Resolved] (OPENJPA-2956) In-memory ID(), set ops and nullPrecedence unimplemented

     [ https://issues.apache.org/jira/browse/OPENJPA-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Maxim Solodovnik resolved OPENJPA-2956.
---------------------------------------
      Assignee: Richard Zowalla
    Resolution: Fixed

> 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
>            Assignee: Richard Zowalla
>            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)