db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fox <Thomas....@seitenbau.net>
Subject TORQUE-177 (SQLFunction interface should extend Column)
Date Tue, 08 May 2012 12:06:27 GMT

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


Mime
View raw message