Hi Alberto, I am thinking that this reminds me a bit of the time (some releases back) when we converted ColumnType from an enum into an interface. That change opened up a lot of doors IMO. And a similar change to the FunctionType could do the trick.
What I have in mind is: * Add an interface called AggregateFunction. This interface will have the "aggregation specific" methods related to AggregateBuilder etc. * Add an interface called ScalarFunction. This interface will have some method that could be used to do the scalar transformation in memory (for those DataContext implementations that don't support the function natively). * Rename the current FunctionType enum into DefaultAggregateFunction and let it implement AggregateFunction * Add a new FunctionType _interface_ which has static final references to the aggregate functions. Thereby we facilitate that existing code will work, although it will need to be recompiled. Once these changes have been done then we can start looking at parsers, how to execute the different types of functions in different kinds of DataContext implementations etc. But having the split in the interfaces will allow us to much better generalize that I think. Best regards, Kasper 2015-07-23 12:28 GMT+02:00 Alberto Rodriguez <[email protected]>: > Hi all, > > I've just started having a look at how to add scalar functions like > SUBSTRING, CONCAT, UPPER... to MetaModel. > > I started by adding these functions to the MetaModel parser. There is > already a FunctionType enum that takes care of all the aggregate functions > (SUM, COUNT, AVG...) This FunctionType is used in the SelectItemParser to > find out the function type and parse it accordingly. > > Not sure if I should add a new "ScalarFunctionType" enum or modify somehow > the existing one to take into account the new scalar functions. I do not > like the idea of having quite different "semantic" elements within the same > enum type but neither like the idea of having to ask everywhere whether the > function is scalar or not. > > I'm thinking of creating kinda enum hierarchical data structure, but still > not sure how to do it because the FunctionType has several methods that are > very coupled to the aggregate functions (abstract AggregateBuilder, > evaluate...) > > Any ideas? > > Kind regards, > > Alberto >
