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 Michael,

Using v.claim in the where clauses causes an inner join to be used. If you want outer joins, you will need to explicitly define them in the from clause, something like: "select v from Vehicle v outer join v.claim claim where v.scenario = :sc and ( is null or in %s)".

Best Regards,

Michael Simons wrote:
Hello Tom,

Taking a look at the sample code using the native API, that you already posted, I changed my
code to:
  Query qu = em.createQuery (String.format ("select v from Vehicle v where v.scenario = :sc and
( is null or in %s)", sb));
  qu.setParameter ("sc", scenario);

  // get the underlying Eclipse query
  ReadAllQuery raq = (ReadAllQuery)((JpaQuery)qu).getDatabaseQuery();

  // get the EclipseLink ExpressionBuilder for the query
  ExpressionBuilder expressBuilder = raq.getExpressionBuilder();

  // build an expression to get the orders
  // orders is 1-m so use anyOf() for join or anyOfAllowingNull() for outer join
  Expression toursExp = expressBuilder.anyOf("tours");

  // build an expression for salesPerson using the already-created
  // ordersExp to indicate to use the same join
  // use get() because this is a 1-1 or getAllowingNull() for outer join
  Expression stopsExp = toursExp.anyOf ("positions");

  // fetch join these two attributes

That generates joins as expected, but of course the join of the "claim" table still leads to the
wrong result.

So I'ld appreciate any hint on how to do the restrition by the claim using the native API.

Kind Regards, Michael

Tom Ware schrieb:
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:

  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.


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 -
Exception Description: You must define a fetch group manager at
(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,

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


Query Hints
There are 4 query hints with some javadoc in


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

   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
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
eclipselink-users mailing list

eclipselink-users mailing list
eclipselink-users mailing list

eclipselink-users mailing list

Back to the top