Re: [hibernate-dev] Lazy attribute loading group support
+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>:
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>
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