| Re: AW: [eclipselink-users] Weaving question |
Hello Tom,
I followed the instructions to give hints to use fetch-grous with JPQL but I get the exception:
Exception [EclipseLink-6114] (Eclipse Persistence Services - 2.0.0.v20091127-r5931):
org.eclipse.persistence.exceptions.QueryException
Exception Description: You must define a fetch group manager at descriptor
(net.uniopt.domain.ot.Vehicle) in order to set a fetch group on the query (null)
How do I have to do that? How do I get the descriptor here?
BTW, I cannot find those @Fetch* annotations that you mentioned. What archive are they in?
I've got eclipselink.jar, javax.persistence-2.0.0.jar, jta-1.0.jar,
org.eclipse.persistence.antlr-2.0.0.jar, org.eclipse.persistence.asm-2.0.0.jar,
org.eclipse.persistence.core-2.0.0.jar, org.eclipse.persistence.jpa-2.0.0.jar
Kind Regards, Michael
Tom Ware schrieb:
> Hi Rafal,
>
> It looks like the documentation about using fetch groups in JPA is a
> little thin. I'll look into getting it beefed up.
>
> Fetch groups can be defined in annotations and query hints. Here are
> some examples from our tests.
>
> Annotations (annotations can be found in
> org.eclipse.persistence.annotations)
> ---
>
> @FetchGroups({
> @FetchGroup(name="HeightAndWidth",
> attributes={
> @FetchAttribute(name="height"),
> @FetchAttribute(name="width")}),
> @FetchGroup(name="Weight", attributes={@FetchAttribute(name="weight")})
> })
>
> Query Hints
> ---
> There are 4 query hints with some javadoc in
> org.eclipse.persistence.config.QueryHints:
>
> "eclipselink.fetch-group"
> "eclipselink.fetch-group.name"
> "eclipselink.fetch-group.attribute"
> "eclipselink.fetch-group.default"
>
> Here are some samples:
>
> // using with a find
> Map properties = new HashMap();
> properties.put(QueryHints.FETCH_GROUP_NAME, "HeightAndWidth");
> Class PadsClass = Pads.class;
> Pads pads = (Pads) em.find(PadsClass, padsId, properties);
>
> // JPQL
> query = em.createQuery("Select employee from Employee employee where
> employee.id = :id");
> query.setHint(QueryHints.FETCH_GROUP_ATTRIBUTE, "firstName");
> query.setHint(QueryHints.FETCH_GROUP_ATTRIBUTE, "lastName");
> query.setParameter("id", employee.getId());
> Employee queryResult = (Employee)query.getSingleResult();
>
> -Tom
>
>
> Swierzynski, Rafal wrote:
>> Hi Tom,
>>
>> thanks for the explanation, it is clear now. The fine grained control
>> over fetch groups is also very nice. Is there a way to define fetch
>> groups in JPA (maybe via properties>) and then to use them in queries
>> (via hints?), without using EclipseLInk native API, as the examples
>> instruct? I tried to look around for info, but couldn't find it.
>>
>> Regards,
>> Rafał
>> ________________________________________
>> Von: eclipselink-users-bounces@xxxxxxxxxxx
>> [eclipselink-users-bounces@xxxxxxxxxxx] im Auftrag von Tom Ware
>> [tom.ware@xxxxxxxxxx]
>> Gesendet: Donnerstag, 4. März 2010 19:36
>> An: EclipseLink User Discussions
>> Betreff: Re: [eclipselink-users] Weaving question
>>
>> Hi Rafal,
>>
>> The way LAZY loading works in EclipseLink for Basic mappings is a bit
>> different from the way it works for xToOne mappings.
>>
>> With xToOne mappings, for each mapping, a structure is weaved in to
>> deal with
>> that mapping and they are dealt with individually.
>>
>> With Basic mappings, we user our Fetch group support. LAZY Basic
>> mappings
>> are excluded from the default fetch group and so the initial query for
>> an object
>> with LAZY basic mappings will not get the objects those mappings refer
>> to. Any
>> reference to a LAZY basic mapping that causes it to be retrieved will
>> cause the
>> whole object to be loaded.
>>
>> The JPA spec defines LAZY as a hint (i.e. there is no mandatory
>> behavior),
>> and that is the way we have chosen to implement that hint for LAZY
>> Basics. If
>> you think this is a major limitation, please feel free to enter an
>> enhancement
>> request.
>>
>> You should be able to use Fetch groups to configure which parts of
>> the object
>> are loaded more finely. Here is some info:
>>
>> http://wiki.eclipse.org/Configuring_a_Descriptor_%28ELUG%29#Configuring_Fetch_Groups
>>
>>
>> As far as the weaved classes are concerned, we use ASM for byte
>> code weaving.
>> The debugging behavior you see is the default behavior when using
>> that tool.
>>
>> -Tom
>>
>> Swierzynski, Rafal wrote:
>>> Hi EL users and devs,
>>>
>>> after seeing some email on weaving in SE, I decided to try this
>>> myself. I configured it and it works. However, I noticed something
>>> strange.
>>> My @Entity class is very simple: Id (Long), Name (String, eager),
>>> Huge (String, lazy). Now when I invoke EntityManager.find() the first
>>> SQL is:
>>> SELECT ID, NAME FROM PERSON WHERE (ID = ?)
>>> which proves that Huge is lazy loaded. Now, I get this via a getter,
>>> and the SQL generated is this:
>>> SELECT ID, HUGE, NAME FROM PERSON WHERE (ID = ?)
>>>
>>> As you can see, the same data (Id and Name in this case) is selected
>>> twice from the database. In my case it is very little data, but I can
>>> imagine a scenario when a lot of data gets selected twice. Maybe I am
>>> missing some configuration property?
>>>
>>> Then, I added another LAZY field, huge2. They don't get selected at
>>> first, as planned, but when I reference any of the lazy fields, both
>>> are selected.
>>>
>>> Are these 2 use cases supposed to work this way, or should I
>>> configure something additionally?
>>>
>>> As a side question: to satisfy my curiosity, I output and decompiled
>>> the weaved class, and the source is much different. However, I could
>>> debug through the entity, and it worked fine, the breakpoints were
>>> put in the appropriate lines and the debugger worked perfectly, it
>>> was totally invisible that the class's bytecode was changed and
>>> didn't correspond to the (original) source. How did you do this? What
>>> magic did you use for that? Do you mess with the internal class
>>> file's sumbol tables somehow to map the new bytecode to the old
>>> source or something?
>>>
>>> Regards,
>>> Rafał
>>> _______________________________________________
>>> 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
>