Regarding HHH-10267... 5.1 will include a new feature allowing users to specify groups for (bytecode enhanced) lazy attribute loading. In the original support accessing one of these lazy attributes forced them all to be loaded[1]. For example... @Entity public class Company { ... @Basic( fetch = FetchType.LAZY ) private String taxIdNumber; @Lob @Basic( fetch = FetchType.LAZY ) private Blob logo; } Once an application accessed any of the lazy attributes, they were all loaded/initialized. So accessing `getTaxIdNumber()` would force `logo` to be fetched as well. The new feature here is the ability to segment attributes into different groups for lazy loading: @Entity public class Company { ... @Basic( fetch = FetchType.LAZY ) private String taxIdNumber; @Lob @Basic( fetch = FetchType.LAZY ) @LazyGroup( "lobs" ) private Blob logo; } `@LazyGroup( "lobs" )` designates that `logo` is part of a specific fetch group. Now, when the application accesses `getTaxIdNumber()`, `logo` is no longer fetched at the same time. P.S. A related question is this idea of `(a)LazyToOne(LazyToOneOption.NO_PROXY)`. At the moment that is still needed for "legacy reasons". The underlying reason is that we don't (didn't) know when the to-one container is enhanced, so we rely on the user telling us. I'd like to plan on dropping the requirement for the user to tell us this. If they are using enhancement I am 99% certain they want NO_PROXY so it seems redundant to make them tell us. Unless I am missing some use case. Any thoughts? [1] Technically the legacy bytecode enhancement treated collections differently than other attribute types in this regard. The new enhancement does the same as the default. _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

+1 it's a useful thing. Instead of using Strings to identify loading groups, would it be better to use class literals? It'd prevent wrong loads due to typos and would help to identify the attributes of one group e.g. in the IDE. But it would add the overhead for defining the groups: public interface Lobs /* extends LoadGroup (maybe have some marker interface?) */ {} And then: @LazyGroup( Lobs.class ) private Blob logo; I am not sure whether it'd pull its weight, but am keen to learn what others think. Cheers, --Gunnar 2015-11-16 22:51 GMT+01:00 Vlad Mihalcea <mihalcea.vlad(a)gmail.com&gt;: > Hi, > > Sounds like a good idea. I like the lazy fetch profiles. Previously it > required the Blob to be moved to a different table. > > Vlad > > > > Vlad > > On Mon, Nov 16, 2015 at 11:09 PM, Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> Regarding HHH-10267... >> >> 5.1 will include a new feature allowing users to specify groups for >> (bytecode enhanced) lazy attribute loading. In the original support >> accessing one of these lazy attributes forced them all to be loaded[1]. >> For example... >> >> @Entity >> public class Company { >> ... >> @Basic( fetch = FetchType.LAZY ) >> private String taxIdNumber; >> @Lob >> @Basic( fetch = FetchType.LAZY ) >> private Blob logo; >> } >> >> Once an application accessed any of the lazy attributes, they were all >> loaded/initialized. So accessing `getTaxIdNumber()` would force `logo` to >> be fetched as well. The new feature here is the ability to segment >> attributes into different groups for lazy loading: >> >> @Entity >> public class Company { >> ... >> @Basic( fetch = FetchType.LAZY ) >> private String taxIdNumber; >> @Lob >> @Basic( fetch = FetchType.LAZY ) >> @LazyGroup( "lobs" ) >> private Blob logo; >> } >> >> `@LazyGroup( "lobs" )` designates that `logo` is part of a specific fetch >> group. Now, when the application accesses `getTaxIdNumber()`, `logo` is no >> longer fetched at the same time. >> >> P.S. A related question is this idea of >> `(a)LazyToOne(LazyToOneOption.NO_PROXY)`. At the moment that is still needed >> for "legacy reasons". The underlying reason is that we don't (didn't) know >> when the to-one container is enhanced, so we rely on the user telling us. >> I'd like to plan on dropping the requirement for the user to tell us this. >> If they are using enhancement I am 99% certain they want NO_PROXY so it >> seems redundant to make them tell us. Unless I am missing some use case. >> Any thoughts? >> >> [1] Technically the legacy bytecode enhancement treated collections >> differently than other attribute types in this regard. The new enhancement >> does the same as the default. >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev