From torque-dev-return-11057-apmail-db-torque-dev-archive=db.apache.org@db.apache.org Tue May 8 12:07:00 2012 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 09F85C526 for ; Tue, 8 May 2012 12:07:00 +0000 (UTC) Received: (qmail 18797 invoked by uid 500); 8 May 2012 12:06:59 -0000 Delivered-To: apmail-db-torque-dev-archive@db.apache.org Received: (qmail 18772 invoked by uid 500); 8 May 2012 12:06:59 -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 18761 invoked by uid 99); 8 May 2012 12:06:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 May 2012 12:06:59 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.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; Tue, 08 May 2012 12:06:53 +0000 Received: from www.seitenbau.net ([192.168.15.18]:6661) by mail.seitenbau.net with esmtp (Exim 4.76) (envelope-from ) id 1SRjBU-0001gz-1A for torque-dev@db.apache.org; Tue, 08 May 2012 14:06:28 +0200 X-CTCH-RefID: str=0001.0A0B0208.4FA90C44.0126,ss=1,re=0.000,fgs=0 Sensitivity: MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: Subject: TORQUE-177 (SQLFunction interface should extend Column) From: Thomas Fox To: torque-dev@db.apache.org X-MIMETrack: MIME-CD by Notes Server on www/seitenbau(Release 8.5HF467 | May 15, 2009) at 05/08/2012 14:06:27, MIME-CD complete at 05/08/2012 14:06:27, Serialize by Router on www/seitenbau(Release 8.5HF467 | May 15, 2009) at 05/08/2012 14:06:27 Message-ID: Date: Tue, 8 May 2012 14:06:27 +0200 X-Mailer: Lotus Domino Web Server Release 8.5HF467 May 15, 2009 Content-type: text/plain; charset=US-ASCII X-Virus-Checked: Checked by ClamAV on apache.org I have thought about the jira issue TORQUE-177 (SQLFunction interface should extend Column) and would like to implement the issue the following way: The following steps are necessary for implementing the Column interface by SQLFunction - rename method toSQL to getSqlExpression to match column interface - add the getColumnName method by always returning null - add the getTableName method: parse all arguments for a column, and extract all non-null table names. If exactly one table name is found, return it, otherwise return null. - add the getSchemaName method analogous to the getTableName method. I'd also like to make the following changes to improve function handling - Make FunctionEnum an enum FunctionEnum is a java 1.4 emulation of an enum. Now that we use Java 1.5 the enum should be a real enum. - Change the class name of FunctionEnum to AggregateType The name FunctionEnum suggests that it is an enum which contains all function. This is not true, it contains only the SQL99 Aggregate functions. This behavior would IMHO be better reflected by the new name. - Make the AggregateFunction argument handling more type safe remove the setArguments() method and replace them by set/getColumn() and set/getDistinct(). Additional constructors should be there to allow constructions in one step, e.g. AggregateFunction(String function, Column column, boolean distinct) Count(Column column) Count(Column column, boolean distinct) - Change the ways aggregate functions are created Currently, the FunctionFactory creates an aggregate function either by by calling the functionInstance Method or by calling a dedicated method (count, sum ...) which then calls the functionInstance method. This method then calls the Adapter to get the class to instantiate and then instantiate the class using reflection. This could be simplified by the following (mutually excluding) methods: a) All database we support use the same SQL syntax for aggregate functions. So there is no need to call the driver at all. The Instantiation of the functions would happen by a normal constructor call in the functionInstance method. b) For the same reasons of a), we could even get rid of FunctionFactory and make the functions top-level classes (currently they are inner classes) and giving them decent type-safe constructors. So instead of writing FunctionFactory.count(someColumn) one would write new Count(someColumn) which is shorter to write and we have one class less. c) if the call to the Adapter is retained, then the adapter should do the instantiation via constructor call and return the function instance. This way we can get rid of the reflection code. My personal preference is b) - If the class FunctionFactory is retained, change its name to AggregateFunctionFactory. The name FunctionFactory suggests that it is an factory for all functions. This is not true, it is only a factory for the SQL99 Aggregate functions. This behavior would IMHO be better reflected by the new name. Are the above changes ok ? Any comments or suggestions are, as always, welcome. Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org For additional commands, e-mail: torque-dev-help@db.apache.org