Closed beikov closed 4 days ago
Please clarify this behavior. I assume that the TCK test is simply wrong and hereby challenge it.
@lukasj could you please add the challenge
label and if you agree that the test should be changed or excluded for Persistence 3.1, please accept the challenge. Please also indicate what you want the Platform TCK team to do (exclude or back port the https://github.com/jakartaee/platform-tck/pull/1259 change).
Thank you!
@lukasj do you approve of this challenge for com/sun/ts/tests/jpa/core/criteriaapi/metamodelquery/Client.java#fetchTest ?
Please add the TCK challenge
label and accept or reject if possible.
@gavinking could you please add the challenge
label to this issue. Thanks
Thanks @lukasj, I'll go ahead and exclude com/sun/ts/tests/jpa/core/criteriaapi/metamodelquery/Client.java#fetchTest_from_standalone
for this challenge. I'll release a new 3.1 JPA TCK with this exclude.
I'll see what the equivalent exclude is for the Platform TCK and make that change for when we soon release the EE 10 Platform TCK (we expect to release for Tags challenges soon).
Addressed via https://github.com/jakartaee/platform-tck/pull/1294 which references the wrong issue number but has the correct changes so will stick with it so we can release the fix.
This challenge can be closed as the updated TCK has been promoted.
Excellent, thanks everyone!
There is a TCK test that calls
FetchParent#fetch
for the same attribute multiple times, but with different join types.Recently in Hibernate ORM, we decided to forbid this sort of nonsense by throwing an exception, but we are clearly failing the TCK now due to this one test. The specification does not say anything about whether this is allowed or disallowed, nor does it clarify what the result of such an operation should be. I assume that the TCK test is not trying to test this scenario, but was rather written this way for convenience.
Please clarify this behavior. I assume that the TCK test is simply wrong and hereby challenge it.