From torque-dev-return-10297-apmail-db-torque-dev-archive=db.apache.org@db.apache.org Sat May 14 17:37:18 2011 Return-Path: X-Original-To: apmail-db-torque-dev-archive@www.apache.org Delivered-To: apmail-db-torque-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 16AD261D4 for ; Sat, 14 May 2011 17:37:18 +0000 (UTC) Received: (qmail 54197 invoked by uid 500); 14 May 2011 17:37:18 -0000 Delivered-To: apmail-db-torque-dev-archive@db.apache.org Received: (qmail 54174 invoked by uid 500); 14 May 2011 17:37:18 -0000 Mailing-List: contact torque-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Apache Torque Developers List" Reply-To: "Apache Torque Developers List" Delivered-To: mailing list torque-dev@db.apache.org Received: (qmail 54166 invoked by uid 99); 14 May 2011 17:37:18 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 14 May 2011 17:37:17 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [217.24.207.26] (HELO mail.seitenbau.net) (217.24.207.26) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 14 May 2011 17:37:10 +0000 Received: from [192.168.15.18] (port=1662 helo=www.seitenbau.net) by mail.seitenbau.net with esmtp (Exim 4.69) (envelope-from ) id 1QLIlj-0003OC-1m for torque-dev@db.apache.org; Sat, 14 May 2011 19:36:47 +0200 X-CTCH-RefID: str=0001.0A0B0209.4DCEBDAF.00BC,ss=1,fgs=0 In-Reply-To: References: Subject: RE: Torque 4 next steps X-KeepSent: B182CCAF:61B39650-C1257890:00608768; type=4; name=$KeepSent To: "Apache Torque Developers List" X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Thomas Fox Date: Sat, 14 May 2011 19:36:51 +0200 X-MIMETrack: Serialize by Router on www/seitenbau(Release 8.5HF467 | May 15, 2009) at 05/14/2011 19:36:46 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Virus-Checked: Checked by ClamAV on apache.org > > - split peer classes ito normal objects plus static wrappers > > The idea would be to make all methods non-static and rename the classes > to > > XXXPeerImpl. Then there would be a static wrapper class named XXXPeer > which > > can create an instance of XXXPeerImpl on demand (or it can get an > instance > > injected). This wrapper class has the same static methods as the current > > Peer class but delegates each method call to its XXXPeerImpl instance. > > There would be a getter and a setter for the XXXPeerImpl instance. > > My question now is where the constants (e.g. for table name and column > > names) should go to ? For source compatiblility, they should be in the > > static wrapper class. Logically, they should be in the XXXPeerImpl class > > because everything should also work without using the static wrappers. > > I do not see another solution than keeping the constants in both the > > XXXPeer and XXXPeerImpl classes, but maybe I have missed something ? > > After more thought and a test implemetation, the PeerImpl classes need to > have access to the other peer classes (e.g. for the doSelectJoinYYY > methods). The easiest way to achieve this is via the other Peer's static > wrappers (the other possibility would be an external dependency injection > framework, which is not overwise needed and too heavyweight for our > problem). > So my new insight is that the implementations cannot exist without the > static wrappers, and in this case it would make no sense to duplicate the > static constants in the Peer and PeerImpl classes, they would stay in the > Peer (static wrapper). > > Then, another question arose, and this is where the RecordMapper classes > (which are responsible for converting resultSets into DB Objects) should > reside. In the first shot when replacing village, they were made inner > static classes of the Peer classes. Now the question is should they be > inner classes of the Peer or the PeerImpl class, or should they be defined > in their own class. As there is no reason to make them inner classes of > either Peer or PeerImpl, my opinion is they should best be defined outside > the Peers and in their own class files. > > Are there objections against committing a discussion basis to trunk or > should I create a branch for it ? The division between static wrappers and the implementation in Peers is now in SVN. It should now be possible to exchange Peer implemetations by using the setter in the respective Peer class. If you sislike something, please email. Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org For additional commands, e-mail: torque-dev-help@db.apache.org