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.
