Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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):
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.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
> = :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:
>>    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:
>>> which proves that Huge is lazy loaded. Now, I get this via a getter,
>>> and the SQL generated is this:
>>> 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
>> _______________________________________________
>> eclipselink-users mailing list
>> eclipselink-users@xxxxxxxxxxx
>> _______________________________________________
>> eclipselink-users mailing list
>> eclipselink-users@xxxxxxxxxxx
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx

Back to the top