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
