The GitHub Actions job "Code Style" on grails-core.git/feat/gorm-count-returns-long-8.0.x has failed. Run started by GitHub user codeconsole (triggered by codeconsole).
Head commit for run: af0be5ee7133418788c688d82747fd57f2c96170 / Scott Murphy Heiberg <[email protected]> Return Long from count() instead of narrowing to Integer GormStaticOperations declared `Integer count()`, but the datastore has always produced a Long: COUNT(*) is a 64-bit value in SQL. Every backend narrowed the result to satisfy the declared type, and each did it differently — GormStaticApi called intValue(), Hibernate 5 cast the Number, Hibernate 7 coerced with `as Integer`. intValue() truncates silently, so a table with more than Integer.MAX_VALUE rows reported a wrong and possibly negative count without failing. Declare what the query actually returns. 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 and anything overriding these methods need updating, so 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/34176491939 With regards, GitHub Actions via GitBox
