That sounds impressive, deleting redundant code is always a good thing. On H5, I would not rush removijg it. Security risks are low to zero. When porting an older app to a newer Grails there is already some work and a lot of testing to do even keeping H5.
Can’t we just deprecate it and declare it is a frozen legacy module somehow? With new apps there is no issue moving to the latest Grails + H7. I am thinking about some apps we have where the cost of moving and testing and maybe fixing some issues after the deployment in production is not justified. I don’t know, my feeling is that switching to a new ORM to manage my old databases is costly with no real value: if the database is working with H5 today, it will work with H5 for other 10 years, since security is not an issue and the database is an inner detail that BTW evolves much slower that the rest. The database we are building today are the same we were building in the late 90s with MS SQL Server. The cost for Grails would be to make sure H5 keeps working with the evolution of the framework, for example the plugin subsystem or other stuff, but basically make sure the H5 plugin runs. Maybe these are just my worries, but that’s my opinion on H5. Gianluca Sartori -- https://dueuno.com On Wed, 21 Oct 2026 at 03:24, Walter Duque de Estrada via dev < [email protected]> wrote: > Team: > > I cant attend the am meetings so I will tell you about 2 major changes > that I have in Hibernate modules in Grails 10.0.x > > Native domain binding in GORM for Hibernate 7: > > PR #16568 adds native domain binding to grails-data-hibernate7. Instead of > GrailsDomainBinder building Hibernate's boot model by hand (about 5,800 > lines that re-implement what Hibernate's annotation binder already does), > GORM now generates a JPA-annotated class for each domain class from its > evaluated mapping and lets Hibernate's own annotation binder bind it. The > application's real domain classes remain what Hibernate persists, loads, > queries and proxies; the generated classes exist only while the mappings > are bound. > > The code lives in one package, > org.grails.orm.hibernate.cfg.domainbinding.jpa, with the value records in > the subpackage jpa.facets. > > How it is verified. The specs under grails.gorm.tests.generated run the > same behaviour through both bindings. Two differential specs compare, for > every scanned test domain class (about 1,170 entities and 3,400 > properties), what the generator states against what the classic binder > bound, both at the Hibernate boot-model level and at the DDL level. The > classic side is frozen as recorded data under > src/test/resources/classic-oracle, so the comparison survives the removal > of the classic binder in #16570. The whole core suite also runs through the > generated classes. > > The same reading order is now in a package-info in the jpa package and in > the hibernate-developer skill, and in the "Where to start reading" section > at the top of the PR description. > > Removal of H5: > > This was EOLed a long time ago. > > Thanks > > Walter > >
