[
https://issues.apache.org/jira/browse/TOMEE-4641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Markus Jung updated TOMEE-4641:
-------------------------------
Description:
h2. Description
Repositories built by openejb-jakarta-data materialize and inject fine. The bug
sits in the query each repository method runs. Six methods declare
{{CursoredPage}} as the return type, but the provider hands back a plain
{{PageRecord}} instead, so the call fails with a {{ClassCastException}}.
Eight {{@Query}} methods use JDQL with a literal, a {{NOT}}, an {{OR}},
parentheses, an empty clause, or a partial select. The provider turns each of
these into JPQL that EclipseLink cannot parse, and the call fails with a syntax
error. Six more methods build a derived query body against an
unmapped-superclass entity; the provider fails to compile the generated
{{SELECT}} for count, exists, and {{ignoreCase}} state-field paths. Four
methods rely on a static metamodel or a find-first derived method, and the
provider cannot resolve either.
Ten methods depend on sort order: {{Sort}}, {{Order}}, and {{PageRequest}} sort
precedence, including the 1.0.1 enum-ordinal sort added for the certification
service release, is not applied, and multi-column projections come back as raw
{{Object[]}} instead of the declared shape. The remaining two methods call an
update {{@Query}} method, and the provider runs it as a select, so no rows
change.
All 36 methods sit in one TCK class, {{standalone.entity.EntityTests}}, and
reduce to one root cause: the JPQL/JDQL the provider generates does not match
what each method needs, across six separate code paths in query generation.
h2. Steps to reproduce / TCK reference
* TCK: Jakarta Data TCK 1.0.1, class
{{ee.jakarta.tck.data.standalone.entity.EntityTests}}
* Failing methods (36 total, listed with reason in the exclusion file
comments): {{testCursoredPageOf7FromCursor}}, {{testCursoredPageOfNothing}},
{{testCursoredPageWithoutTotalOf9FromCursor}},
{{testCursoredPageWithoutTotalOfNothing}},
{{testFirstCursoredPageOf8AndNextPages}},
{{testFirstCursoredPageWithoutTotalOf6AndNextPages}},
{{testCommonInterfaceQueries}}, {{testEmptyQuery}}, {{testLiteralInteger}},
{{testLiteralTrue}}, {{testPartialQuerySelectAndOrderBy}},
{{testQueryWithNot}}, {{testQueryWithNull}}, {{testQueryWithParenthesis}}, plus
the derived-query, static-metamodel/find-first, sort-precedence, and
update-query groups documented in the exclusion file.
* Currently excluded in: {{runner-standalone/exclusions/data.txt}} in the
apache/tomee-tck harness repo.
* To confirm a fix: remove the relevant line(s) from {{data.txt}} and rerun the
Data TCK standalone module; the method must pass against the TomEE Plume
snapshot.
was:
h2. Summary
openejb-jakarta-data generates wrong or broken queries for 36 Jakarta Data TCK
1.0.1 EntityTests methods.
h2. Description
Repositories built by openejb-jakarta-data materialize and inject fine. The bug
sits in the query each repository method runs. Six methods declare
{{CursoredPage}} as the return type, but the provider hands back a plain
{{PageRecord}} instead, so the call fails with a {{ClassCastException}}.
Eight {{@Query}} methods use JDQL with a literal, a {{NOT}}, an {{OR}},
parentheses, an empty clause, or a partial select. The provider turns each of
these into JPQL that EclipseLink cannot parse, and the call fails with a syntax
error. Six more methods build a derived query body against an
unmapped-superclass entity; the provider fails to compile the generated
{{SELECT}} for count, exists, and {{ignoreCase}} state-field paths. Four
methods rely on a static metamodel or a find-first derived method, and the
provider cannot resolve either.
Ten methods depend on sort order: {{Sort}}, {{Order}}, and {{PageRequest}} sort
precedence, including the 1.0.1 enum-ordinal sort added for the certification
service release, is not applied, and multi-column projections come back as raw
{{Object[]}} instead of the declared shape. The remaining two methods call an
update {{@Query}} method, and the provider runs it as a select, so no rows
change.
All 36 methods sit in one TCK class, {{standalone.entity.EntityTests}}, and
reduce to one root cause: the JPQL/JDQL the provider generates does not match
what each method needs, across six separate code paths in query generation.
h2. Steps to reproduce / TCK reference
* TCK: Jakarta Data TCK 1.0.1, class
{{ee.jakarta.tck.data.standalone.entity.EntityTests}}
* Failing methods (36 total, listed with reason in the exclusion file
comments): {{testCursoredPageOf7FromCursor}}, {{testCursoredPageOfNothing}},
{{testCursoredPageWithoutTotalOf9FromCursor}},
{{testCursoredPageWithoutTotalOfNothing}},
{{testFirstCursoredPageOf8AndNextPages}},
{{testFirstCursoredPageWithoutTotalOf6AndNextPages}},
{{testCommonInterfaceQueries}}, {{testEmptyQuery}}, {{testLiteralInteger}},
{{testLiteralTrue}}, {{testPartialQuerySelectAndOrderBy}},
{{testQueryWithNot}}, {{testQueryWithNull}}, {{testQueryWithParenthesis}}, plus
the derived-query, static-metamodel/find-first, sort-precedence, and
update-query groups documented in the exclusion file.
* Currently excluded in: {{runner-standalone/exclusions/data.txt}} in the
apache/tomee-tck harness repo.
* To confirm a fix: remove the relevant line(s) from {{data.txt}} and rerun the
Data TCK standalone module; the method must pass against the TomEE Plume
snapshot.
> Jakarta Data query generation produces wrong or broken JPQL for 36
> EntityTests methods
> --------------------------------------------------------------------------------------
>
> Key: TOMEE-4641
> URL: https://issues.apache.org/jira/browse/TOMEE-4641
> Project: TomEE
> Issue Type: Bug
> Reporter: Markus Jung
> Priority: Major
>
> h2. Description
> Repositories built by openejb-jakarta-data materialize and inject fine. The
> bug sits in the query each repository method runs. Six methods declare
> {{CursoredPage}} as the return type, but the provider hands back a plain
> {{PageRecord}} instead, so the call fails with a {{ClassCastException}}.
> Eight {{@Query}} methods use JDQL with a literal, a {{NOT}}, an {{OR}},
> parentheses, an empty clause, or a partial select. The provider turns each of
> these into JPQL that EclipseLink cannot parse, and the call fails with a
> syntax error. Six more methods build a derived query body against an
> unmapped-superclass entity; the provider fails to compile the generated
> {{SELECT}} for count, exists, and {{ignoreCase}} state-field paths. Four
> methods rely on a static metamodel or a find-first derived method, and the
> provider cannot resolve either.
> Ten methods depend on sort order: {{Sort}}, {{Order}}, and {{PageRequest}}
> sort precedence, including the 1.0.1 enum-ordinal sort added for the
> certification service release, is not applied, and multi-column projections
> come back as raw {{Object[]}} instead of the declared shape. The remaining
> two methods call an update {{@Query}} method, and the provider runs it as a
> select, so no rows change.
> All 36 methods sit in one TCK class, {{standalone.entity.EntityTests}}, and
> reduce to one root cause: the JPQL/JDQL the provider generates does not match
> what each method needs, across six separate code paths in query generation.
> h2. Steps to reproduce / TCK reference
> * TCK: Jakarta Data TCK 1.0.1, class
> {{ee.jakarta.tck.data.standalone.entity.EntityTests}}
> * Failing methods (36 total, listed with reason in the exclusion file
> comments): {{testCursoredPageOf7FromCursor}}, {{testCursoredPageOfNothing}},
> {{testCursoredPageWithoutTotalOf9FromCursor}},
> {{testCursoredPageWithoutTotalOfNothing}},
> {{testFirstCursoredPageOf8AndNextPages}},
> {{testFirstCursoredPageWithoutTotalOf6AndNextPages}},
> {{testCommonInterfaceQueries}}, {{testEmptyQuery}}, {{testLiteralInteger}},
> {{testLiteralTrue}}, {{testPartialQuerySelectAndOrderBy}},
> {{testQueryWithNot}}, {{testQueryWithNull}}, {{testQueryWithParenthesis}},
> plus the derived-query, static-metamodel/find-first, sort-precedence, and
> update-query groups documented in the exclusion file.
> * Currently excluded in: {{runner-standalone/exclusions/data.txt}} in the
> apache/tomee-tck harness repo.
> * To confirm a fix: remove the relevant line(s) from {{data.txt}} and rerun
> the Data TCK standalone module; the method must pass against the TomEE Plume
> snapshot.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
