Personally I find that to be too much work to set up.
On Wed, Nov 18, 2015 at 2:52 AM Gunnar Morling <gun...@hibernate.org> wrote:
> +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.v...@gmail.com>:
> > 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 <st...@hibernate.org>
> > 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
> >> `@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@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
