The GitHub Actions job "CI" on grails-core.git/feat/gorm-count-returns-long-8.0.x has succeeded. Run started by GitHub user codeconsole (triggered by codeconsole).
Head commit for run: cdeffcf2863f9221288496e587ec55034f404269 / Scott Murphy Heiberg <[email protected]> Return Long from count() instead of narrowing to Integer GormStaticOperations declared `Integer count()`. How wide the value underneath actually is depends on the datastore: Hibernate counts with SQL COUNT(*) and Neo4j with Cypher count(*), both 64-bit, while MongoDB aggregates with {$sum: 1}, which returns Int32 and promotes to Int64 once the total exceeds it. Only the in-memory datastore is fixed at 32 bits. GormStaticApi normalises all of them with longValue(), and the declared return type then narrowed the result again with intValue(). That second step truncates silently, so a collection or table with more than Integer.MAX_VALUE rows reported a wrong and possibly negative count without failing — and MongoDB, where the width varies with collection size, is exactly where that is most likely to bite. Long is the only type that holds every value a datastore can produce here. Declaring it removes the narrowing rather than moving it around, in GormStaticApi, both Hibernate backends, TenantDelegatingGormOperations, GormEntity, RestfulController and the GraphQL count fetcher, whose schema field was typed Int and truncated for the same reason. MongoDB and Neo4j inherit GormStaticApi and needed no change of their own. RestfulServiceController loses its Math.toIntExact call, because the service it delegates to already returned a Long and was narrowing only to fit the controller signature. Dynamic Groovy is unaffected: `Book.count() == 5` and `int n = Book.count()` still work, because Groovy converts and compares numeric types by value. Statically compiled callers, Java callers relying on unboxing, and overrides of these methods need updating, as does any generated GraphQL client, since the schema field becomes `personCount: Long`. All of this is documented in the 8.0 upgrade notes. Typed views bind their model by reflective Field.set with no coercion, in GSP and in JSON views alike, so a view naming a concrete numeric type fails when the other scaffolding path supplies the other type. The scaffolded index.gsp and the two product index.gson views now declare Number, and HalViewHelper.paginate accepts a Number total so a count can reach it without being narrowed again on the way in. The scaffolded index.gsp change also appears in the fix for the Integer declaration it previously carried; the two resolve to the same line. Report URL: https://github.com/apache/grails-core/actions/runs/34180694403 With regards, GitHub Actions via GitBox
