openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abe White <>
Subject Re: svn commit: r510281 - in /incubator/openjpa/trunk: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/ openjpa-kernel/src/main/java/org/apache/openjpa/kernel/ openjpa-persistence/src/main/java/org/apache/openjpa/persistence/
Date Tue, 27 Feb 2007 16:36:40 GMT
> What's the word on this issue?

Last record I have is:

> Okay, I think we need to back out these last two changes and revert  
> back to
> revision 509885.  Dave needs to go back to the drawing board for  
> this "db2
> optimization" change, probably create a JIRA report for this proposed
> change, and use the design discussion associated with the JIRA  
> process to
> get the proper fix in place.

But that doesn't seem to have happened.

And just so they don't get lost, here were my responses to Patrick's  

> 3. OpenJPA does support a means of passing Oracle hints along  
> through to
> the DBDictionary. Should we be trying to reuse some of the  
> capabilities
> here?


> 4. In the following snippets, I'd rather if we used 'Integer.valueOf 
> (1)'
> or, better yet, a symbolic constant, instead of creating new  
> integer all
> the time.
>> +        fetch.setHint("openjpa.hint.optimize", new Integer(1));
>> +    	_query.getFetchConfiguration().
>> +    		setHint("openjpa.hint.optimize", new Integer(1));

Use serp.util.Numbers.valueOf(x).
But actually I think both of these calls have to be more thoroughly  
re-thought.  The FetchConfiguration is around for the life of the  
Broker/Query, and you're setting a hint on it that only applies to  
the very next call.  What about all the other uses of the Broker or  
possible other executions of the Query?

> 5. I don't like the name 'openjpa.hint.optimize', as it's a bit
> ambiguous as to what's being optimized. I don't really know what
> 'optimize for' does, so I'm just guessing here, but how about
> 'openjpa.ExpectedRecordCount'?

+1  But should be openjpa.hint.XXX -- see OracleDictionary.SELECT_HINT.

I think we should move all this to a  
SelectExecutor.ExpectedResultCount property.  It could replace the  
current Union.isSingleResult property.  The user can set an expected  
result count via the Query hint API, and it will get set into the  
Select.  In cases where a query range is set the property will return  
the max - min of the range.  And in cases where we know there's only  
one result like find() calls (actually JDBCStoreManager.load) we can  
use the property directly internally.  The DBDictionary can then ask  
the Select for the expected count and do what it wants with it when  
creating the SQL.

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

View raw message