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 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)

    @FetchGroup(name="Weight", attributes={@FetchAttribute(name="weight")})

Query Hints
There are 4 query hints with some javadoc in org.eclipse.persistence.config.QueryHints:


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);

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();


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.

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

   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.


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?

eclipselink-users mailing list
eclipselink-users mailing list

eclipselink-users mailing list

Back to the top