RepositoryImpl not producing expected JPQL for FindById method

[fermentedDairy]

Description
When using the CrudRepository from Jakarta Data, the repositoryImpl generates the JPQL SELECT o FROM Section o WHERE (o.bookstore.id=?1). trace.log extract:

[3/16/24, 11:42:36:735 SAST] 00000035 id=708abff3 io.openliberty.data.internal.persistence.RepositoryImpl > invoke SectionRepository.findById Entry
5fc2f396-afa0-4897-855b-02a4115cfe52 [3/16/24, 11:42:36:735 SAST] 00000035 id=708abff3 io.openliberty.data.internal.persistence.RepositoryImpl 3 QueryInfo@3ce7c286 Optional findById(Object) SELECT o FROM Section o WHERE (o.bookstore.id=?1) [1 positional params] [3/16/24, 11:42:36:735 SAST] 00000035 id=708abff3 io.openliberty.data.internal.persistence.RepositoryImpl 3 createQuery SELECT o FROM Section o WHERE (o.bookstore.id=?1) org.fermented.dairy.data.rest.entity.jpa.Section

Steps to Reproduce
JPA entities and Repositories are attached as well as trace.log

Expected behavior
The expected JPQL is SELECT o FROM Section o WHERE (id=?1). JPQL generated for attached Bookstore entity is as expected: SELECT o FROM Bookstore o WHERE (o.id=?1)

Diagnostic information:

• OpenLiberty Version: 24.0.0.3-beta
• Affected feature(s): data-1.0
• Java Version:

  openjdk version "21.0.1" 2023-10-17 LTS OpenJDK Runtime Environment Temurin-21.0.1+12 (build 21.0.1+12-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.1+12 (build 21.0.1+12-LTS, mixed mode, sharing)

JakartaData.zip

[njr-11]

Thank you for reporting this and providing the entity and repository classes. I have switched this issue from release bug to bug because it is beta function that is still in development. We will look into it to see what is going wrong.

[fermentedDairy]

Just a note, removing the foreign key relationship from both the bookstore and section JPA entity lead to the JPQL being generated correctly. For some reason the query generation code is using the wrong ID.

[njr-11]

I reproduced the issue and located the problem in the code, which is a place where it is overwriting the id value. I fixed it locally and will look into getting the fix into the upcoming 24.0.0.5-beta

[njr-11]

This should be corrected in the 24.0.0.5-beta