Branch: refs/heads/7.2 Home: https://github.com/hibernate/hibernate-orm Commit: 10c9e44a57dd1be799ba5bcc1a7a2868a69d2910 https://github.com/hibernate/hibernate-orm/commit/10c9e44a57dd1be799ba5bc... Author: Stéphane Épardaud <stef(a)epardaud.fr&gt; Date: 2026-02-20 (Fri, 20 Feb 2026) Changed paths: M tooling/metamodel-generator/src/main/java/org/hibernate/processor/HibernateProcessor.java M tooling/metamodel-generator/src/main/java/org/hibernate/processor/annotation/AnnotationMetaEntity.java Log Message: ----------- HHH-20151 Metamodel geneartor: allow implicit repositories for Panache Next Fixes https://github.com/quarkusio/quarkus/issues/50178 Commit: 484505a1988c1635268523447575ece5e36ea51b https://github.com/hibernate/hibernate-orm/commit/484505a1988c16352685234... Author: Stéphane Épardaud <stef(a)epardaud.fr&gt; Date: 2026-02-20 (Fri, 20 Feb 2026) Changed paths: M tooling/metamodel-generator/src/main/java/org/hibernate/processor/HibernateProcessor.java Log Message: ----------- HHH-20163 Metamodel generator: do not visit nested types twice I added the indexQueryInterfaces method before the elements were recursively visited to find nested entities. I did not realise we were visiting nested types twice: once with the primaryEntity set (by indexQueryInterfaces) and the second time without it, causing issues with nested repositories losing their primaryEntity in Quarkus Panache. I'm now removing indexQueryInterfaces in favour of the upstream recursion, adapted for keeping track of implicit primaryEntity. Commit: e03b94eafb8120435014ff675d9240f141c429b9 https://github.com/hibernate/hibernate-orm/commit/e03b94eafb8120435014ff6... Author: Stéphane Épardaud <stef(a)epardaud.fr&gt; Date: 2026-02-20 (Fri, 20 Feb 2026) Changed paths: M tooling/metamodel-generator/src/main/java/org/hibernate/processor/annotation/AnnotationMetaEntity.java Log Message: ----------- HHH-20164 Metamodel processor: Fixed bug with missing catch clause for @Delete queries This only happens in Quarkus Panache when we have an implicit JD repository with a @Delete query method, because jakartaDataRepository is not set, but it should not matter, because this method is only defined by JD for repositories, so I don't think it makes any sense for it to be false. The result was code like this: @Override public long deleteByTitle(String title) { var _builder = session.getCriteriaBuilder(); var _query = _builder.createCriteriaDelete(Panache2Book.class); var _entity = _query.from(Panache2Book.class); _query.where( title==null ? _entity.get(Panache2Book_.title).isNull() : _builder.equal(_entity.get(Panache2Book_.title), title) ); try { return session.createMutationQuery(_query).executeUpdate(); } Note the missing catch. This is because the catch is conditional on jakartaDataRepository while the try is not conditional. Commit: 7b926ded12e9d19f8a244be7a7bbf9fda120edf5 https://github.com/hibernate/hibernate-orm/commit/7b926ded12e9d19f8a244be... Author: Stéphane Épardaud <stef(a)epardaud.fr&gt; Date: 2026-02-20 (Fri, 20 Feb 2026) Changed paths: M tooling/metamodel-generator/src/main/java/org/hibernate/processor/annotation/AnnotationMetaEntity.java M tooling/metamodel-generator/src/main/java/org/hibernate/processor/annotation/CDIAccessorMetaAttribute.java Log Message: ----------- HHH-20165 Processor: avoid generating conflicting names for repositories Compare: https://github.com/hibernate/hibernate-orm/compare/27fc1370e763...7b926de... To unsubscribe from these emails, change your notification settings at https://github.com/hibernate/hibernate-orm/settings/notifications