[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: AW: [eclipselink-users] Weaving question
|
Hello Tom,
unfortunately using a milestone i sno option for us.
You can take a look at the stack trace below.
Here's what I have done:
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)); // sb is a String like "(1, 78, 3, 7, 9)"
qu.setParameter ("sc", scenario);
qu.setHint(QueryHints.FETCH_GROUP_ATTRIBUTE, "tours");
List<Vehicle> result = qu.getResultList (); // throws Exception, shown below
Withut the query hint the generated SQL is:
SELECT t0.vehicle_id, t0.jdo_version, ...
FROM vehicle t0, claim t1
WHERE (((t0.scenario_id = ?)
AND ((t1.claim_id IS NULL) OR (t1.claim_id IN (?, ?, ?, ?))))
AND (t1.claim_id = t0.claim_id))
Like mentioned in another thread joining the claim is wrong here because it makes the "or
t1.claim_id is null" clause useless. But that's another problem. I hope this will work with the
native API.
Kind Regards, Michael
Stack Trace:
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)
Query: ReadAllQuery(referenceClass=Vehicle sql="SELECT t0.vehicle_id, t0.jdo_version,
t0.max_weight, t0.height, t0.cost_per_distance, t0.lngth, t0.alt_ex_id_2, t0.empty_weight,
t0.plate_no, t0.alt_ex_id, t0.width, t0.ext_id, t0.cost_per_use, t0.number_of_axles,
t0.cost_per_trip, t0.cost_per_time, t0.measure_id, t0.toll_exhaust_id, t0.depot_id, t0.claim_id,
t0.vehicle_type_id, t0.schedule_id, t0.scenario_id, t0.caution_id, t0.corporate_id,
t0.time_unit_id, t0.plan_vehicle_id, t0.distance_unit_id FROM vehicle t0, claim t1 WHERE
(((t0.scenario_id = ?) AND ((t1.claim_id IS NULL) OR (t1.claim_id IN (?, ?, ?, ?, ?, ?, ?, ?, ?,
?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)))) AND (t1.claim_id = t0.claim_id))")
Local Exception Stack:
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)
Query: ReadAllQuery(referenceClass=Vehicle sql="SELECT t0.vehicle_id, t0.jdo_version,
t0.max_weight, t0.height, t0.cost_per_distance, t0.lngth, t0.alt_ex_id_2, t0.empty_weight,
t0.plate_no, t0.alt_ex_id, t0.width, t0.ext_id, t0.cost_per_use, t0.number_of_axles,
t0.cost_per_trip, t0.cost_per_time, t0.measure_id, t0.toll_exhaust_id, t0.depot_id, t0.claim_id,
t0.vehicle_type_id, t0.schedule_id, t0.scenario_id, t0.caution_id, t0.corporate_id,
t0.time_unit_id, t0.plan_vehicle_id, t0.distance_unit_id FROM vehicle t0, claim t1 WHERE
(((t0.scenario_id = ?) AND ((t1.claim_id IS NULL) OR (t1.claim_id IN (?, ?, ?, ?, ?, ?, ?, ?, ?,
?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)))) AND (t1.claim_id = t0.claim_id))")
at
org.eclipse.persistence.exceptions.QueryException.fetchGroupValidOnlyIfFetchGroupManagerInDescriptor(QueryException.java:1240)
at
org.eclipse.persistence.queries.ObjectLevelReadQuery.prepareQuery(ObjectLevelReadQuery.java:1988)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.prepare(ObjectLevelReadQuery.java:1797)
at org.eclipse.persistence.queries.ReadAllQuery.prepare(ReadAllQuery.java:722)
at org.eclipse.persistence.queries.DatabaseQuery.checkPrepare(DatabaseQuery.java:464)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.checkPrepare(ObjectLevelReadQuery.java:732)
at org.eclipse.persistence.queries.DatabaseQuery.checkPrepare(DatabaseQuery.java:430)
at org.eclipse.persistence.queries.DatabaseQuery.execute(DatabaseQuery.java:646)
at org.eclipse.persistence.queries.ObjectLevelReadQuery.execute(ObjectLevelReadQuery.java:958)
at org.eclipse.persistence.queries.ReadAllQuery.execute(ReadAllQuery.java:432)
at
org.eclipse.persistence.queries.ObjectLevelReadQuery.executeInUnitOfWork(ObjectLevelReadQuery.java:1021)
at
org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.internalExecuteQuery(UnitOfWorkImpl.java:2863)
at
org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1225)
at
org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1207)
at
org.eclipse.persistence.internal.sessions.AbstractSession.executeQuery(AbstractSession.java:1181)
at org.eclipse.persistence.internal.jpa.EJBQueryImpl.executeReadQuery(EJBQueryImpl.java:453)
at org.eclipse.persistence.internal.jpa.EJBQueryImpl.getResultList(EJBQueryImpl.java:669)
at de.optitool.persistence.Eval.run(Eval.java:84)
at de.optitool.persistence.Eval.main(Eval.java:97)
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
