[clarification]: do we really need countBy methods returning int

[gavinking]

Specification

Query by Method Name

I need clarification on ...

In the module-level javadoc one can discover the requirement that a countByXxxxx() query may have the return type int instead of long. This obviously dates from before we had JDQL. Now, JDQL (and JPQL) define that the type of count(this) is long.

I would prefer to align these things so that counts are always consistently long everywhere, removing the requirement for providers to support countByXxxxx() methods returning int. (Providers are always free to allow this if they wish to.)

Additional information

This would mean changing the return type of some methods in the TCK from int to long.

[njr-11]

If I were writing a repository method that I know cannot possibly ever return a larger count, I think it would be a best practice to return int because that spares the repository user from needing to code for a safe cast from long to int, so I would say we should consider allowing int for JDQL as well, although it would be fine to not have int for now and allow it in the future.

[gavinking]

I mean the thing is that to support this I had to hack in a truly awful special case into my previously-reasonably-clean code, just for this one trivial thing.

One of my characteristics is I just hate ad hoc special cases of this sort, because they lead to a multiplication of special cases and consequent bugs down the road.

[gavinking]

(I mean, sure, it's worse than it otherwise would be because we're compiling Query by Method Name to @Query and JDQL instead of just interpreting it directly. But the spec should in principle make that possible.)

[otaviojava]

Specification

Query by Method Name

I need clarification on ...

In the module-level javadoc one can discover the requirement that a countByXxxxx() query may have the return type int instead of long. This obviously dates from before we had JDQL. Now, JDQL (and JPQL) define that the type of count(this) is long.

I would prefer to align these things so that counts are always consistently long everywhere, removing the requirement for providers to support countByXxxxx() methods returning int. (Providers are always free to allow this if they wish to.)

Additional information

This would mean changing the return type of some methods in the TCK from int to long.

For simplicity and sync with the API that is already "on Production," I would vote to put it as a long

[njr-11]

I don't want to expand function in version 1.0 or require special cases like this, so I think it makes sense to take the approach of restricting countBy... to long. I think in future versions we might want to consider if there are ways to be more tolerant to the user on return types because there is value to letting the repository writer better control what the repository user can expect to receive as return values because it can simplify things for the repository user. But for now, go ahead and update the doc to state that it is always long for count.

[gavinking]

I think in future versions we might want to consider if there are ways to be more tolerant to the user on return types

Yes, I already started thinking about that: we can definitely consider specifying some well-defined implicit type conversions that work in general, but I would do that starting in the Persistence spec and working up the stack. So that em.createQuery("select count(this) from Book", int.class).getSIngleResult() would work instead of throwing an error as today.