openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dick" <michael.d.d...@gmail.com>
Subject Re: OPENJPA-182: reuse Connection constants or create our own?
Date Fri, 06 Apr 2007 21:09:25 GMT
Adding in enum-based methods seems like a good idea to me.

There isn't much harm in starting here and finishing the rest of FetchPlan
later, so long as we do it someday.

On 4/6/07, Patrick Linskey <plinskey@bea.com> wrote:
>
> 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.
>



-- 
-Michael Dick

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message