Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] Fetchgroup usage / unfetched basic attributes 
Hi Andrei,
so if LoadGroup has no effect on basic attributes, why are they loaded if we change from FetchGroup to LoadGroup?
And is there a way to get control on the sql generation behaviour? In Your example below, if we put a LoadGroup containing "address" on a Employee query, we could image the adress to be joined to the employee which results in 1 and not in 1 + n sql queries.
Best regards, Markus


-----Ursprüngliche Nachricht-----
Von: eclipselink-users-bounces@xxxxxxxxxxx [mailto:eclipselink-users-bounces@xxxxxxxxxxx] Im Auftrag von Andrei Ilitchev
Gesendet: Dienstag, 6. September 2011 15:44
An: eclipselink-users@xxxxxxxxxxx
Betreff: Re: [eclipselink-users] Fetchgroup usage / unfetched basic attributes


 > it looks like all basics are loaded even if they are not noted in the 
LoadGroup. Does this happen by accident?
No

 > Or can You confirm this behaviour as intended?
Yes

LoadGroup set into a query causes its reference fetch="LAZY" attributes 
to be loaded right away (to behave as if they were fetch="EAGER"), it 
has no effect on basic and EAGER reference attributes.

Say, we have an Employee class that has a OneToOne reference to Address 
class:
@OneToOne(fetch=LAZY)
@JoinColumn(name="ADDR_ID")
private Address address;

A query
"SELECT e FROM Employee e WHERE employee.firstName = 'John'"
without a LoadGroup will select a ForeignKey ADDR_ID from Employee 
table, but it won't read the Address object:
calling on the Employee returned by the query employee.getAddress() will 
cause a query on Address to be executed.

However if LoadGroup containing "address" attribute is set into the 
query then Employee's Address object would be read in right away (it 
still will be a separate sql).


Now if a FetchGroup is set to the query that does not include "address" 
attribute then ADDR_ID won't be read in at all. Calling 
employee.getAddress() on query result would cause reading the whole 
Employee object again (now with ADDR_ID field), then reading Address 
from the db.

Therefore it does not really makes sense to put a fetch="LAZY" reference 
into a FetchGroup - all you are saving is not reading a ForeignKey from 
a row you are reading anyway.

Thanks,
Andrei

On 9/6/2011 8:29 AM, Hahn, Markus wrote:
> Hi Andrei,
> we found out that using LoadGroup instead of FetchGroup fits better to our needs, it looks like all basics are loaded even if they are not noted in the LoadGroup. Does this happen by accident?
No
Or can You confirm this behaviour as intended?
Yes
We didn't find anything in the docs.
> Best regards, Markus
>
> -----Ursprüngliche Nachricht-----
> Von: eclipselink-users-bounces@xxxxxxxxxxx [mailto:eclipselink-users-bounces@xxxxxxxxxxx] Im Auftrag von Andrei Ilitchev
> Gesendet: Freitag, 2. September 2011 15:22
> An: eclipselink-users@xxxxxxxxxxx
> Betreff: Re: [eclipselink-users] Fetchgroup usage / unfetched basic attributes
>
> Hi Markus,
>
> If there is no LAZY basics and a query is executed without a FetchGroup
> then all basics are fetched.
>
> In other words lack of a FetchGroup is equivalent to a FetchGroup that
> includes all the attributes.
>
> Default FetchGroup is created automatically if there is at least one
> basic attribute annotated with fetch=LAZY.
> It would make sense to use fetch=LAZY for a basic attribute if it's
> mapped to potentially huge object that is rarely used (for instance
> array of bytes mapped to a Blob).
>
> If something like that is not the case then I would not use fetch=LAZY
> for basics.
>
> Thanks,
> Andrei
>
> On 9/2/2011 6:03 AM, Hahn, Markus wrote:
>> Hi Andrei,
>> 1. simple example: I suppose, the cases where we get the basics loaded, are those without Fetchgroups so it fits to what you said.
>> 2. what we are trying to do? Well, we migrated from JDO to JPA, and that's the default in JDO. In general, I am convinced that it would be a valuable feature to include the basic mappings in a default Fetchgroup which can be a starting point to enlarge. What is an entity without basics like Strings, Long, Integer?
>> Thanks a lot and best regards, Markus
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: eclipselink-users-bounces@xxxxxxxxxxx [mailto:eclipselink-users-bounces@xxxxxxxxxxx] Im Auftrag von Andrei Ilitchev
>> Gesendet: Donnerstag, 1. September 2011 16:39
>> An: eclipselink-users@xxxxxxxxxxx
>> Betreff: Re: [eclipselink-users] Fetchgroup usage / unfetched basic attributes
>>
>> Comments are inline.
>> On 9/1/2011 10:20 AM, Hahn, Markus wrote:
>>> Hi Andrei,
>>> thanks a lot. But then i dont understand why we have so many use cases where we define a Fetchgroup without basic attributes on a query, and despite of not included in the Fetchgroup they are loaded in the entities. What could cause this behaviour?
>> Could you please provide a simple example.
>>> And is there a convenient way to build a Fetchgroup including all the basic attributes?
>> I don't think there is anything like that.
>> What are you trying to do?
>> To always fetch all basic attributes just don't define them as LAZY -
>> and you would not need any fetch group on queries.
>> And use a FetchGroup when you need to NOT fetch some basic attributes.
>>> Best regards, Markus
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: eclipselink-users-bounces@xxxxxxxxxxx [mailto:eclipselink-users-bounces@xxxxxxxxxxx] Im Auftrag von Andrei Ilitchev
>>> Gesendet: Donnerstag, 1. September 2011 15:16
>>> An: eclipselink-users@xxxxxxxxxxx
>>> Betreff: Re: [eclipselink-users] Fetchgroup usage / unfetched basic attributes
>>>
>>> Hi Markus,
>>>
>>> If you don't use a fetch group with a query the only basic attributes
>>> that are NOT fetched are those defined as "fetch=LAZY".
>>>
>>> Alternatively, if you use a fetch group with a query the only basic
>>> attributes fetched are those included in the fetch group.
>>>
>>> Thanks,
>>> Andrei
>>>
>>> On 9/1/2011 6:14 AM, Hahn, Markus wrote:
>>>> Hi folks,
>>>> we use the EL Fetchgroup features and encounter some behaviour we cant
>>>> explain.
>>>> In many cases, EL works as expected concerning the basic mappings
>>>> (String, Long..): the attributes are fetched if they are not mapped as
>>>> "fetch=LAZY", independently of using a Fetchgroup on the query. Basic
>>>> mappings don't have to be included in the Fetchgroup.
>>>> In some cases, this does not work: the basic attributes are NOT loaded.
>>>> If we add them to our Fetchgroup, they are loaded.
>>>> Is it a bug? Does anybody has a hint how to solve this problem?
>>>> Best Regards, Markus
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> eclipselink-users mailing list
>>>> eclipselink-users@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>>> _______________________________________________
>>> eclipselink-users mailing list
>>> eclipselink-users@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>>> _______________________________________________
>>> eclipselink-users mailing list
>>> eclipselink-users@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>> _______________________________________________
>> eclipselink-users mailing list
>> eclipselink-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>> _______________________________________________
>> eclipselink-users mailing list
>> eclipselink-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

Back to the top