Hi Pinaki,
Your example is perfect - exactly what I was looking for. Thank-you very
much for your help. I very much appreciate it!
Pinaki Poddar wrote:
>
> Hi Steven,
> To include selective fields of an embedded relation via @FetchGroup
> annotation is bit complicated because when field names are parsed, the
> types may not have been resolved.
>
> For concreteness, assume the following domain entitiy definitions,
>
> @Entity
> public class Person {
> @Id
> private long id;
> private String name;
> @Embedded
> private Address address;
> }
>
> @Embeddable
> public class Address {
> private String city;
> private String zip;
> }
>
> And, say, we want to fetch the following fields when we fetch a Person
> instance:
> Person.address
> Person.address.city
> and we do not want to fetch
> Person.name
> Person.address.zip
>
> A straightforward annotation specification in Person.java *should* have
> been
> @FetchGroup(name="Person.Address.CityOnly",
> attributes={
> @FetchAttribute(name="address"),
> @FetchAttribute(name="address.city")
> })
>
> Unfortunately "address.city" fetch attribute specification dose not work.
> Because when Person.java is being parsed, we can ascertain that "address"
> is one of its field. But we can not ascertain that Address has a field
> named "city" -- simply because we may not have parsed Address.java at that
> time.
>
> So the alternative solution is to define the FetchGroup twice, with the
> same moniker.
>
> In Person.java
> @FetchGroup(name="Person.Address.CityOnly",
> attribute...@fetchattribute(name="address")})
>
> And again in Address.java
> @FetchGroup(name="Person.Address.CityOnly",
> attribute...@fetchattribute(name="city")})
>
> Now at runtime, one can do
> OpenJPAEntityManager em = ...;
> FetchPlan plan = em.getFetchPlan();
> plan.addFetchGroup("Person.Address.CityOnly");
> plan.removeFetchGroup(FetchPlan.GROUP_DEFAULT); // otherwise
> Person.name will be fetched as part
>
> //of the default group
>
>
> Of course, it is not necessary to define the fetch groups with same
> moniker. But then, at runtime, one has to add two fetch groups.
>
> If the fetch plan is *dynamically* defined as in my previous post then
> that problem does not arise.
>
>
> StevenK wrote:
>>
>>>Sorry it's taken me so long to respond. I was out of the office for the
holidays. First, thanks for responding to my post. When I added the fields
to the group, I added the annotation on a class like this:
>> @FetchGroup(name="myFetchGroup",
>> attribute...@fetchattribute(name="fieldOne"),
>> @FetchAttribute(name="embeddableFieldTwo"}). I didn't qualify the fields
>> by naming them MyClass.fieldOne or MyEmbeddableClass.embeddableFieldTwo.
>> Do you think that adding the class name to the field name this way would
>> have been enough to make it work?
>>
>>
>>
>>
>> Pinaki Poddar wrote:
>>>
>>>> We created a fetch plan that includes a couple of embedded fields and a
>>>> couple of non-embedded fields.
>>>
>>> Can you post the exact definition of the plan? Th eplan needs to include
>>> the individual fields of the embeddded type. For example, if Person has
>>> reference to Address (which is Embeddable) then
>>>
>>> plan.addField(Person.class, "name");
>>> plan.addField(Person.class, "address");
>>> plan.addField(Address.class, "city");
>>>
>>> will fetch a Person whose address is poulated *only* with city.
>>>
>>> A SQL similar to following should be generated:
>>> select t0.name, t0.city from Person t0
>>>
>>>
>>> StevenK wrote:
>>>>
>>>> We created an entity that contained some embedded fields and some
>>>> non-embedded fields (string, ints, etc). All fields are lazy loaded
>>>> (the default). We created a fetch plan that includes a couple of
>>>> embedded fields and a couple of non-embedded fields. We then created a
>>>> query that uses the fetch plan.
>>>>
>>>> We created a test that added a number of these entities to the
>>>> database. We then looped through all the entities that were returned
>>>> by the query and accessed each field. We turned sql tracing on so we
>>>> could see what sql was generated and executed. What we found was that
>>>> when we accessed the non-embedded fields, no sql was executed (we
>>>> expected this because these fields were included in the fetch plan).
>>>> When we accessed the embedded fields sql was executed (selects for
>>>> those fields) indicating that the fields were still being lazy loaded
>>>> and the fetch plan was not eagerly loading the data. We did not expect
>>>> this as these fields were also part of the fetch plan.
>>>>
>>>> Have you worked with fetch plans that combined embedded and
>>>> non-embedded fields? Any idea what might be causing this?
>>>>
>>>> Thanks for your help.
>>>>
>>>> Pinaki Poddar wrote:
>>>>>
>>>>>> Are their any restrictions, constraints, or other complications that
>>>>>> anyone is aware of?
>>>>> Nothing specific comes to mind. Are you seeing any anomaly w.r.t.
>>>>> embedded fields in a fetch plan?
>>>>>
>>>>>
>>>>> StevenK wrote:
>>>>>>
>>>>>> I am trying to optomize a query by using fetch groups. One of the
>>>>>> fields I'd like to include in the group is an embedded entity. When
>>>>>> I turn sql tracing on, run my query, and then display the value of
>>>>>> the fields that were returned, I can see that the non-embedded fields
>>>>>> in my entry display without additional selects from the database -
>>>>>> which is exactly what I expect. The embedded fields however generate
>>>>>> a select to the database to get their contents - which I am trying to
>>>>>> avoid by including those fields in the fetch group. Has anyone else
>>>>>> worked with fetch groups and embedded fields? Are their any
>>>>>> restrictions, constraints, or other complications that anyone is
>>>>>> aware of?
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
--
View this message in context:
http://n2.nabble.com/FetchGroups-and-Embeddable-Fields-tp4200062p4253242.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
