From torque-dev-return-10282-apmail-db-torque-dev-archive=db.apache.org@db.apache.org Mon May 9 20:03:21 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 87CBD4FCF for ; Mon, 9 May 2011 20:03:21 +0000 (UTC) Received: (qmail 84168 invoked by uid 500); 9 May 2011 20:03:21 -0000 Delivered-To: apmail-db-torque-dev-archive@db.apache.org Received: (qmail 84136 invoked by uid 500); 9 May 2011 20:03:20 -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 84128 invoked by uid 99); 9 May 2011 20:03:20 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 May 2011 20:03:20 +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; Mon, 09 May 2011 20:03:12 +0000 Received: from [192.168.15.18] (port=5364 helo=www.seitenbau.net) by mail.seitenbau.net with esmtp (Exim 4.69) (envelope-from ) id 1QJWfK-0005Bm-25 for torque-dev@db.apache.org; Mon, 09 May 2011 22:02:50 +0200 X-CTCH-RefID: str=0001.0A0B0202.4DC8486A.0163,ss=1,fgs=0 Subject: Torque 4 next steps X-KeepSent: 47D897B4:2412951A-C125788B:00405C58; 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: Mon, 9 May 2011 22:02:51 +0200 X-MIMETrack: Serialize by Router on www/seitenbau(Release 8.5HF467 | May 15, 2009) at 05/09/2011 22:02:49 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Virus-Checked: Checked by ClamAV on apache.org I will hopefully have some time the next month to go further towards a torque 4 release. My next future plan would be the following (detailed below) - split peer classes ito normal objects plus static wrappers - remove remnants from village usage from om classes - remove the inheritance of criteria from hashtable - remove Criteria.Criterion.db For each of these points, I need opinions on how to proceed - 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 ? - remove remnants from village usage from om classes This would mean removing the getOMClass() method, the CLASS_DEFAULT constant and the initClass() method in the generated peers. They were needed to create instances of the database object classes but this is not necessary any more with the mapper classes. Any objections here ? - remove the inheritance of criteria from hashtable The reasons for suggesting this are: - Criteria is not a logical specialisation of a Hash map. - To retain current signatures and comply with java5 generics, Criteria would have to be declared as HashMap, while technically it is a HashMap - the current "put" method does not follow the contract of a Map's put method: Criteria.put() returns the Criteria itself, whereas Map.put() returns the value which previously had the passed key. Also, if you put() an object into a criteria and then get() the same key, you do not receive the object you put() but a Criteria.Criterion containing the object you put in. This is also not the behaviour expected by a map. If we remove the inheritance from Hashtable, we might want to consider the semantics of the Criteria.add() methods. Currently, if one adds a column twice, the first assignment is overwritten by the second. For example: Criteria criteria = new Criteria(); criteria.add(AuthorPeer.AUTHOR_ID, 100, Criteria.GREATER_THAN); criteria.add(AuthorPeer.AUTHOR_ID, 200, Criteria.LESS_THAN); ends up in the SQL select ... from author where author.author_id < 200; which is not at all what one would expect by reading the code (I would expect select ... from author where author.author_id > 100 and author.author_id < 200). I see the following possiblilities 1) leave the semantics as it is 1a) possibly deprecating the add() methods and encourage users to use and () instead 2) change the semantics such that add() does not override existing keys (i.e. they would do the same as the and() methods) 2a) as 2) but additionally deprecating the add() methods 3) remove the add() method altogether I am not sure what to do. In a clean room implementation one would want to go for 2) or 3) but 3) severely breaks current applications and 2) may introduce bugs in applications depending on the current behaviour. 1) is the least pain for existing users but the maximum pain for new users. 1b) might be a good alternative, maybe with the possibility to remove the add methods later. Also, we might either deprecate or remove the put, putAll and get methods, as they do not make sense for a criteria. What do you think ? - remove Criteria.Criterion.db The db field of the Criterion specifies which database dialect is used for rendering this Criterion in SQL. As a criterion is no standalone class, but an inner class of a Criteria, it always has a criteria attached and its SQL is only rendered in the context of this criteria. As the criteria has a field dbName by which the db adapter can be found out via Torque.getDB (criteria.getDbName()), I propose to remove the db field from Criterion together with its getters and setters and use the dbName field of the criteria instead to determine which Adapter should be used. Any objections ? Thanks for your opinions, Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org For additional commands, e-mail: torque-dev-help@db.apache.org