[TCK Challenge]: The TCK contains a repository method with an UPDATE query that returns boolean but this is not allowed in the spec and Javadoc

[OndroMih]

Specification

data/tck/src/main/java/ee/jakarta/tck/data/standalone/entity/MultipleEntityRepo.java

Line 54 in 8adf740

boolean move(UUID id, double newX, float yDivisor);

Assertion

data/tck/src/main/java/ee/jakarta/tck/data/standalone/entity/EntityTests.java

Line 2465 in 8adf740

assertEquals(true, shared.move(id1, 1.23d, 1.5f));

TCK Version

1.0.1

Implementation being tested

JNoSQL Jakarta Persistence Extension

Challenge Scenario

Claims that a test asserts requirements over and above that of the specification.

Full Description

The test testUpdateQueryWithWhereClause in

data/tck/src/main/java/ee/jakarta/tck/data/standalone/entity/EntityTests.java

Line 2465 in 8adf740

assertEquals(true, shared.move(id1, 1.23d, 1.5f));

asserts that the return value from calling the move method is true. However, it's not clear what the return value should represent.

The move method in the MultipleEntityRepo class is annotated with @Query,which contains an UPDATE statement. I didn't find anywhere in the spec of javadoc any mention of what should be returned in this case.

On the contrary, the spec suggests that returning a boolean type is forbidden in this case:

• The @Query Javadoc says: "For select statements, the return type of the query method must be consistent with the type returned by the query. For update or delete statements, it must be void, int or long."
• In the specification document: "implementations are encouraged to support void as the return type for a query which never returns a result"

Additional Context

I suggest that the method move in MultipleEntityRepo is modified to return void and remove the assertion.

A future version of the Data spec could introduce the boolean return type and clarify what it means. it could e.g. mean that it's true when a long type would return > 0, false otherwise.

It would also be good to clarify what the int and long return types mean, whether methods should return the number of modified entities or > 0 if some entities modified, or it a value of > 0 means an error. It's not no clearly stated anywhere in the spec of javadocs, I only assume it's the number of modified entities based on the assertions in the TCK tests.

Is there an existing challenge for this?

• I have searched the existing issues

[njr-11]

@OndroMih nice work finding this inconsistency between the TCK and what is documented for valid return types of @Query. My vote is for accepting this TCK challenge because boolean which is used by the test case is not an allowed return type for @Query. If others agree and this challenge is accepted, then you should be able to run the TCK excluding this test failure to certify a compatible implementation.

I'll look into putting together a PR to fix the test and improve the spec JavaDoc for Data 1.1. For the fix in 1.1, I will plan to switch the test from boolean to int or long so that we still have coverage for @Query with an UPDATE statement having a return value.

[gavinking]

Yes, I believe I argued against requiring this, so leaving it out was deliberate, assuming my memory doesn't mislead.

[OndroMih]

It looks like the tests expect return value true when count > 0, so this inconsistency doesn’t block my implementation.