db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-672) Re-enable user defined aggregates
Date Wed, 18 Jul 2012 09:36:35 GMT

    [ https://issues.apache.org/jira/browse/DERBY-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416960#comment-13416960

Knut Anders Hatlen commented on DERBY-672:

The proposal looks good to me. I would be fine with either of the two alternatives, but I
agree that alternative (ii) sounds more elegant. It might also be more flexible, as adding
optional clauses to the syntax later is probably easier than adding more parameters to existing

I have no objections to restricting new features to modern platforms. By using parameterized
types, the user doesn't have to cast the parameter in the accumulate() method, and it is checked
at compile time that the value returned from terminate() has the correct type.

It does however still seem to me that the user will have to cast the otherAggregator parameter
that's passed to the merge() method, as the implementation in most cases will need to access
fields/method of the instance that's passed in. Example (reimplementing the SUM aggregate
function for integers):

public class MyIntSum implements Aggregator<Integer,Integer> {
  private int sum;
  public void init() { sum=0; }
  public void accumulate(Integer value) { sum += value; }
  public void merge(Aggregator<Integer,Integer> otherAggregator) {
    MyIntSum that = (MyIntSum) otherAggregator;
    this.sum += that.sum;
  public Integer terminate() { return sum; }

Not sure what's the cleanest way to handle this. Maybe we could add a third parameterized
type that tells which kind of aggregators it can be merged with. That would mean changing
the interface declaration like this:

public interface Aggregator<V, R, T extends Aggregator<V,R,T>> extends Serializable
public void merge( T otherAggregator ) throws SQLException;

and MyIntSum would become:

public class MyIntSum implements Aggregator<Integer,Integer,MyIntSum> {
  private int sum;
  public void init() { sum=0; }
  public void accumulate(Integer value) { sum += value; }
  public void merge(MyIntSum that) { this.sum += that.sum; }
  public Integer terminate() { return sum; }

It makes the declaration a little more messy, but the implementation becomes more concise
and statically type-checked.
> Re-enable user defined aggregates
> ---------------------------------
>                 Key: DERBY-672
>                 URL: https://issues.apache.org/jira/browse/DERBY-672
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>            Reporter: Rick Hillegas
> Nicolas Dufour in an email thread titled "functions and list" started on November 2,
2005 requests the ability to create user defined aggregates.
> This functionality used to be in Cloudscape. It was disabled presumably because it was
considered non-standard. However, most of the machinery needed for this feature is still in
the code. We should re-enable user defined aggregates after we agree on acceptable syntax.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message