openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@bea.com>
Subject RE: OPENJPA-182: reuse Connection constants or create our own?
Date Fri, 06 Apr 2007 20:16:20 GMT
FYI, one problem with using an enum is that the rest of FetchPlan uses
symbolic constants, not enums. But, I think that we should deprecate
those methods and add in enum-based methods there when applicable at
some point here, anyways.

-Patrick

-- 
Patrick Linskey
BEA Systems, Inc. 

_______________________________________________________________________
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. 

> -----Original Message-----
> From: Patrick Linskey 
> Sent: Friday, April 06, 2007 12:47 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: OPENJPA-182: reuse Connection constants or create our own?
> 
> Hi,
> 
> There's one last open issue for OPENJPA-182 that I know of. Currently,
> the JDBCFetchPlan.setIsolation() and
> JDBCFetchConfiguration.setIsolation() methods use the 
> symbolic constants
> defined in Connection. Should they, or should we use our own?
> 
> I think that JDBCFetchPlan should take a Java 5 enum, and
> JDBCFetchConfiguration should use the Connection values. The 
> reasons for
> this are:
> 
> 1. enums are nicer than symbolic constants, API-wise
> 
> 2. enums should work more intuitively from XML-based hints or string
> hints (we could make our hint conversion stuff know to try to 
> reflect on
> enums based on their names)
> 
> 3. Since these concepts are exactly the same as the Connection
> constants, in JDBCFetchConfiguration, we should just use them and not
> redefine the wheel.
> 
> Thoughts?
> 
> -Patrick
> 
> -- 
> Patrick Linskey
> BEA Systems, Inc. 
> 
> ______________________________________________________________
> _________
> 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.
> 
> 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.
> 

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.

Mime
View raw message