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: [email protected]
For additional commands, e-mail: [email protected]
