Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: AW: [eclipselink-users] Weaving question 
Hi Michael,
I apologize. The fetch group annotations are only available in our development stream for our 2.1 release (release will be at the beginning of July) I should have been more specific about that. If that version is a possibility, you can find milestones here: 

http://www.eclipse.org/eclipselink/downloads/milestones.php

  If you can use that version, it will likely help your exception.
If not, I can help you get the fetch group set-up with the native API. Can you let me know exactly what you have done and what the full stack of your exception is. 

-Tom

Michael Simons wrote:

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




_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

Back to the top