[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: AW: [eclipselink-users] Weaving question
|
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
(v.claim.id is null or v.claim.id 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
raq.addJoinedAttribute(toursExp);
raq.addJoinedAttribute(stopsExp);
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:
>
> 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
> _______________________________________________
> eclipselink-users mailing list
> eclipselink-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>
