From open-jpa-dev-return-3241-apmail-incubator-open-jpa-dev-archive=incubator.apache.org@incubator.apache.org Fri Apr 06 21:09:48 2007 Return-Path: Delivered-To: apmail-incubator-open-jpa-dev-archive@locus.apache.org Received: (qmail 55295 invoked from network); 6 Apr 2007 21:09:47 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 6 Apr 2007 21:09:47 -0000 Received: (qmail 36182 invoked by uid 500); 6 Apr 2007 21:09:54 -0000 Delivered-To: apmail-incubator-open-jpa-dev-archive@incubator.apache.org Received: (qmail 36160 invoked by uid 500); 6 Apr 2007 21:09:53 -0000 Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: open-jpa-dev@incubator.apache.org Delivered-To: mailing list open-jpa-dev@incubator.apache.org Received: (qmail 36151 invoked by uid 99); 6 Apr 2007 21:09:53 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Apr 2007 14:09:53 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of michael.d.dick@gmail.com designates 209.85.132.241 as permitted sender) Received: from [209.85.132.241] (HELO an-out-0708.google.com) (209.85.132.241) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Apr 2007 14:09:46 -0700 Received: by an-out-0708.google.com with SMTP id b2so1184199ana for ; Fri, 06 Apr 2007 14:09:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=DHeYF3LLO9YJEYmGAO8KTyKP7PhGa9xUnz47u8W5FNy9hxl55zPL9ru3vMqtNwCDesIF2Y7+a24wxKkcnWg5ptU0FMDIp67cnvvc7pjRpsd94Q/R191S+gEs0OovYMyslaaSqzwYsZTeZtlpzaoXrjK9Af/HqY+W1keMxjjgyfM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=cqrY+eoriRqRw913IQz7gts8yovUM8xX6CEEoDT+9FwZXZsQB3xJEr2f6YNOiY9pUZ4IpikYCt6TOHZAyaQinNs3NOW5uusgDwrYjAru7zN2XUk2op8rpyJuL5Lx8eRf5VMIwXws843UNTPieRyvieNPQqlzHirZSt6+2A1tYbA= Received: by 10.100.191.5 with SMTP id o5mr2387642anf.1175893765104; Fri, 06 Apr 2007 14:09:25 -0700 (PDT) Received: by 10.100.6.16 with HTTP; Fri, 6 Apr 2007 14:09:25 -0700 (PDT) Message-ID: <72c1350f0704061409t1edf1ab3pfa05b66a97487648@mail.gmail.com> Date: Fri, 6 Apr 2007 16:09:25 -0500 From: "Michael Dick" To: open-jpa-dev@incubator.apache.org Subject: Re: OPENJPA-182: reuse Connection constants or create our own? In-Reply-To: <7D856CDFE035FF45A0420ACBD71BDD6303D1F507@repbex02.amer.bea.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_14826_10520811.1175893765062" References: <7D856CDFE035FF45A0420ACBD71BDD6303D1F4EA@repbex02.amer.bea.com> <7D856CDFE035FF45A0420ACBD71BDD6303D1F507@repbex02.amer.bea.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_14826_10520811.1175893765062 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 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 ------=_Part_14826_10520811.1175893765062--