OK, NP G 11 Walter
> On Oct 22, 2026, at 1:29 PM, James Daugherty via dev <[email protected]> > wrote: > > Hi Walter, > > I explicitly said we could not remove in 10. 9 will release within the > month. All of our removal policies have always been: set the new feature > as default in a major release, then remove the old feature in the next. > This means you need at least 2 major releases before we can purge the code. > I'm willing to entertain setting it as the default in 10, but I am -1 > against removing it until we're stable. 1 major release is not stable if > we're rewriting the way it works. > > -James > > On Thu, Oct 22, 2026 at 2:00 PM Walter Duque de Estrada <[email protected]> > wrote: > >> Thanks for the feedback >> >> H5 removal is targeted for G10, that should be plenty of time to find all >> bugs in H7 >> >> >> This is the size of the native domain binding branches >> >> >> ┌────────┬───────────────────────────────────────────────────────────────┬───────┬──────────────────┐ >> │ PR │ What it does │ >> Files │ Lines │ >> >> ├────────┼───────────────────────────────────────────────────────────────┼───────┼──────────────────┤ >> │ #16568 │ native domain binding through Hibernate's annotations │ >> 154 │ +37,585 / −290 │ >> >> ├────────┼───────────────────────────────────────────────────────────────┼───────┼──────────────────┤ >> │ #16569 │ make native binding the default, deprecate the classic binder │ >> 28 │ +462 / −145 │ >> >> ├────────┼───────────────────────────────────────────────────────────────┼───────┼──────────────────┤ >> │ #16570 │ delete the classic domain binder │ >> 269 │ +4,035 / −20,615 │ >> >> └────────┴───────────────────────────────────────────────────────────────┴───────┴──────────────────┘ >> >> Thanks >> >> Walter >> >> >>> On Oct 22, 2026, at 11:47 AM, James Daugherty via dev < >> [email protected]> wrote: >>> >>> Several of us have objected to removing Hibernate 5. Until we have a >> major >>> release without rewriting critical Hibernate 7 functions or being forced >> to >>> discontinue Hibernate 5 support due to Spring, I do not believe the >>> Hibernate 7 code line can be considered fully stable. Thus, I'm against >>> removing it. >>> >>> Concerning the domain binder: simplifying the code sounds great, but I >> need >>> to better understand the implications before fully endorsing it. 10.0 >> isn't >>> expected to go live until later in 2027, so we should have plenty of time >>> to work on it. I would just suggest we incrementally make these changes. >>> I personally do not want to review a 3000+ file PR again. I can say with >>> my current commitments, travel, and 8.1/9.0-M1 releases, I don't think >> I'll >>> have time to look until December. >>> >>> On Wed, Oct 21, 2026 at 1:33 AM Gianluca Sartori <[email protected]> >>> wrote: >>> >>>> 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 >>>>> >>>>> >>>> >> >>
