openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject API or Query hints
Date Wed, 04 Apr 2007 22:22:10 GMT
I think any time we make a change to the external view of the project  
we need to have a discussion first.

IMHO The JIRA process is pretty good for this kind of stuff. Someone  
proposes a feature with non-standardized external behavior and writes  
up what it should look like. Then we agree on the details and go for it.

On this particular issue, I can see valid reasons for having an API  
that modifies the behavior of the query, but also understand why it  
might be good to mirror that behavior using query hints. But  
whichever way we go, we need to agree on the name and semantics of  
the API/property and how to pass it to the internal structures for  

There is a danger in thinking of these as "hints". As I would like to  
see it, the only down side to not recognizing a query hint is lower  
performance. But if your application doesn't behave correctly if the  
implementation can't do anything useful with the hint, then it's not  
a hint but an application requirement. And if the hint can only be  
executed in some specific databases, then we need to decide if we  
throw an exception if the database isn't capable.


On Apr 4, 2007, at 2:17 PM, Abe White wrote:

>> ... for certain values of "our". I think that it's important that we
>> discuss API decisions as a group, as they have significant impacts on
>> the OpenJPA product moving forward. This is especially important when
>> there are dissenting views on a particular API decision, as is the
>> case
>> here.
> I agree with Patrick.  API decisions need to be better thought out.
> For example, even if we decide as a group to use hints in this case,
> the names of the hints are important.  The current hint names you
> chose are inconsistent with other OpenJPA hints in naming style and
> capitalization.
> 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.

Craig Russell
Architect, Sun Java Enterprise System
408 276-5638
P.S. A good JDO? O, Gasp!

View raw message