Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] Order of adding Join Attribute Expressions when using Dynamic Persistence

Hi Tom

If I run the generated SQL on my database I get sufficient rows for fetching the required content from the database.

However the problem is more subtle. If I use setUseIndirection(false), the first entity does not contain any entries in the list corresponding to the invoice, but the subsequent entries do contain the required information. But for getting each row it makes an additional query. However without this setting it does not fetch the invoices corresponding to the customer's orders. May be if you could see the code I had attached in my previous mail, you would be able to reproduce the problem. It is either a bug in eclipselink or a flaw in the way I am expecting Eclipselink to behave.

I can try the Logging level and outer joins once I am back on my development machine.

Thanks and Regards
Member Technical Staff 
Oracle Server Technologies


----- Original Message -----
From: tom.ware@xxxxxxxxxx
To: rohit.banga@xxxxxxxxxx
Cc: eclipselink-users@xxxxxxxxxxx, christopher.delahunt@xxxxxxxxxx
Sent: Wednesday, December 22, 2010 8:53:47 PM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi
Subject: Re: [eclipselink-users] Order of adding Join Attribute Expressions when using Dynamic Persistence

Hi Rohit,

   IndirectList is the EclipseLink type that will be used for xToMany 
relationships that are LAZY.

   The best way to diagnose this problem is to take a look at the SQL that is 
generated and determine how you would want it written differently.

   Use session.setLogLevel(SessionLog.FINEST) to get FINEST logging which will 
print the generated SQL.

   Is it possible some of your joins should be outer joins.  (i.e. the fact that 
they are inner joins is removing data from the returned list).   Try using 
expression.anyOfAllowingNull().

-Tom

Rohit Banga wrote:
>   Hello All
> 
> I am responding to an earlier unanswered mail thread that I had started 
> on a query that is similar to the one asked before. In order to shed 
> more light on the issue, I have included a more specific example in this 
> mail.
> 
> I have attached a program to give you an idea of where I am facing a 
> problem. Each type corresponds to a table in the database.
> 
> I have the following questions:
> 
> 1. I am querying customer type for all orders placed by her. Each order 
> has a corresponding invoice. However when I query the order dynamic type 
> for the join attribute *invoice9.order9.invoiceid* then I do not get any 
> invoices. Moreover the type of e2 is IndirectList. If I do not add the 
> exp4 join attribute then I do get the invoice corresponding to the order 
> (List e2 is not empty). Why is this happening?
> 
> 2. If I use setUsesIndirection to false for all the mappings, the first 
> entity does not have any invoices as above however for all other 
> entities I get a Vector instead of an IndirectList which has the 
> expected objects of the dynamic type invoice. In this case the number of 
> accesses to the database is also large. Could you please explain the 
> behavior?
> 
> -- 
> Thanks and Regards
> Rohit Banga
> Member Technical Staff
> Oracle Server Technologies
> 
> 
> On 12/20/2010 10:21 AM, Rohit Banga wrote:
>> Hi Christopher
>>
>> Here is the stack trace:
>>
>> Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 
>> 2, Size: 1
>>     at java.util.ArrayList.add(Unknown Source)
>>     at 
>> org.eclipse.persistence.internal.queries.JoinedAttributeManager.addExpressionAndBaseToGroupedList(JoinedAttributeManager.java:828)
>>     at 
>> org.eclipse.persistence.internal.queries.JoinedAttributeManager.prepareJoinExpressions(JoinedAttributeManager.java:780)
>>     at 
>> org.eclipse.persistence.queries.ObjectLevelReadQuery.prePrepare(ObjectLevelReadQuery.java:2057)
>>     at 
>> org.eclipse.persistence.queries.ObjectLevelReadQuery.checkPrePrepare(ObjectLevelReadQuery.java:834)
>>     at 
>> org.eclipse.persistence.queries.ObjectLevelReadQuery.checkPrepare(ObjectLevelReadQuery.java:817)
>>     at 
>> org.eclipse.persistence.queries.DatabaseQuery.prepareCall(DatabaseQuery.java:1584)
>>
>> Thanks
>>>
>>> Can you post the exception?
>>>
>>>  
>>>
>>>
>>> ----- Original Message -----
>>> From: rohit.banga@xxxxxxxxxx
>>> To: eclipselink-users@xxxxxxxxxxx
>>> Sent: Saturday, December 18, 2010 6:27:18 AM GMT -05:00 US/Canada Eastern
>>> Subject: [eclipselink-users] Order of adding Join Attribute 
>>> Expressions when using Dynamic Persistence
>>>
>>> Hello All
>>>
>>> I have a customer table, a phone table and an order table.
>>> The customer table has a one-to-many with both the phone and order 
>>> tables.
>>>
>>> I am querying the order table.
>>>
>>> If I add the join attributes in the following sequence then it works 
>>> fine:
>>>
>>>         
>>> query.addJoinedAttribute(query.getExpressionBuilder().get("cust9.order9.custid"));
>>>         
>>> query.addJoinedAttribute(query.getExpressionBuilder().get("cust9.order9.custid").anyOf("cust9.phone9.custid"););
>>>
>>> However, if I add in this sequence I get an IndexOutOfBounds Exception.
>>>
>>>         
>>> query.addJoinedAttribute(query.getExpressionBuilder().get("cust9.order9.custid").anyOf("cust9.phone9.custid"););
>>>         
>>> query.addJoinedAttribute(query.getExpressionBuilder().get("cust9.order9.custid"));
>>>
>>>
>>> Could you please explain the reason for this exception? Is it 
>>> expected that the join attributes be passed in a particular order?
>>>
>>> Thanks in Advance.
>>>
>>> -- 
>>> Thanks and Regards
>>> Rohit Banga
>>> Member Technical Staff
>>> Oracle Server Technologies
>>
>> -- 
>> Thanks and Regards
>> Rohit Banga
>> Member Technical Staff
>> Oracle Server Technologies
>>
>>
>> _______________________________________________
>> eclipselink-users mailing list
>> eclipselink-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-users
> 
> -- 
> Thanks and Regards
> Rohit Banga
> Member Technical Staff
> Oracle Server Technologies
> 


Back to the top